> In looking over this thread what I see is 1.) a very bright programmer 2.)
has a good insignt into protential problems, 3.) is unfamiliar with the
Windows kernel-mode software environment but 4.) is in too big of a
hurry…
Thank you, and yeah, there are so many things to take into account when
you’re new to the WDM that it sometimes seems too overwhelming to carefully
read every little detail. That, of course, backfires later on. Sometimes you
need to get dirt on your hand too, though. Thank God for the existence of
people such as those in this newsgroup :]
But, it there still need for some sort of "protection’ on that structure?
Of course there is…
…
So, what you’re saying is that everytime I need to access the adapter
context area from a routine, I need to make use of reference counting etc.
to make sure the memory is still valid. That makes perfect sense as I
wouldn’t want to free the memory when it’s in use.
What about multiple routines accessing the structure at the same time?
According to your example below, one increments the refcount before using
the structure and decrements it after use. If data exists in the structure
which are used by more than one routine, would you then add a spin lock (or
similar) to guard that specific data?
Currently, I do make use of refcounting to see when the last NIC that uses
my driver shuts down (utilizing NdisInterlockedIncrement() /
NdisInterlockedDecrement() to perform the operations in an atomic fashion).
Regarding supporting multiple NICs, if you keep the adapter instances on a
linked list, how does each instance know which linked node belongs to them?
I guess I’m missing something here…
Thank you so very much for the elaborate reply!
“Thomas F. Divine” wrote in message news:xxxxx@ntdev…
>
> “Søren Dreijer” wrote in message news:xxxxx@ntdev…
> > Update:
> > I avoided holding a spin lock when calling NdisMEthIndicateReceive() and
> > that fixed the problem.
> >
> > I’m am still very interested in what a robust solution for managing the
> > adapter context area for multiple NICs would look like. Also, the
> > synchronization question still stands :]
> >
> > Thanks everyone so far!
> >
> In looking over this thread what I see is 1.) a very bright programmer 2.)
> has a good insignt into protential problems, 3.) is unfamiliar with the
> Windows kernel-mode software environment but 4.) is in too big of a
hurry…
>
> It is important for you to take the time to study Windows driver
> fundamentals. Available resources include the DDK, books, training courses
> and the DDK sample drivers.
>
> Back to your original problem…
>
> Elimination of holding the spinlock apparently “fixed” your original
> problem.,
>
> But, it there still need for some sort of "protection’ on that structure?
>
> Of course there is…
>
> For one thing, during some parts of your code execution NDIS is not aware
> that you are doing anything. NDIS could, for example, choose a very bad
> moment to disable your adapter. This sort of thing could result in your
> per-nic structure being deleted - probably at the worst time. So, you must
> take steps to insure that your per-nic instance data continues to exist
> while you are using it. This problem concerns the “lifetime” of objects,
and
> in the kernel it is usually solved by using “reference counting”.
>
> Several of the DDK samples illustrate reference counting. Basically you
add
> a reference counter to a structure whose existance you must insure. A
> spinlock-protected function is provided to increment the refcount to
> indicate that you are using it. A spinlock-protected function is used to
> decrement the regerence count - AND this function is used to “hide” the
code
> that deletes the structure. When the refcount goes (typically) to zero,
the
> decerementing function will delete the structure.
>
> Your original spinlock protection was held too long. It would be replaced
by
> code that 1.) grabs the spinlock, 2.) insures that the info actually
exists,
> 3.) increments info’s refcount if it exists and 4.) releases the spinlock.
> This is a very brief operation. Having done this (successfully) you now
KNOW
> that the per-nic instance data will continue to exist until you are done
> with it. You would (while holding the spinlock…) decrement the reference
> count after you completed your call to NdisMEthIndicateReceive. If you
made
> some sort of longer-duration asynchronous operation, you would hold on the
> the spinlock until the operation is completed.
>
> If you account for multiple nics, the solution is typically to use a
linked
> list of some sort. The global spinlock protects the list head. You may
have
> additional spinlocks associated with each individual NIC instance data so
> you can, for example, safely operate on one NIC’s data without limiting
> access to other NIC’s data.
>
> Finally, take a look at other kernel-mode functions that are extremely
> helpful. In particular, look at the “Interlocked” functions.
>
> Good luck,
>
> Thomas F. Divine, Windows DDK MVP
> http://www.pcausa.com
>
>