The set is discrete because a program is made of sequential instructions and a set is made of elements inserted in a sequential way. So a set is a list and your main object is just a list.
A number of concurrent threads obtain access each to a dedicated unique slot allocated by the main object.
Since it’s uniquely assigned, each thread can and shall treat its assigned slot as its exclusive[*] property.
The main object, does not allocate anything. This is done by the program or driver.
Each thread needs shared access (read-only) to the list to grab its dedicated slot. If that slot does not exist then that thread must create and insert the slot and therefore that thread needs exclusive access (write) to the list.
The main object is analysed and finally it is reset to the original empty state (i.e. all slots are discarded).
Removing all the elements of a list or just adding one element make no difference as you need exclusive access to the list in both cases.
I think you need an ERESOURCE, unless you need to acquire the lock at DISPATCH_LEVEL IRQL in which case you need a shared spin lock. At device IRQL (DIRQL), you must synchronize with an ISR and any access is exclusive
Sent from my Windows 10 phone
De : xxxxx@0xacab.net
Envoyé le :dimanche 2 avril 2017 16:52
À : Windows System Software Devs Interest List
Objet :RE:[ntdev] Interleaved syncronization objects
Thanks everyone for your quick replies.
So the idea is that there is a generic shared object: the main object.
The main object consists of an expanding set of slots which are, with one single exception described later[*], fully independent.
The main object is created with no slots.
A number of concurrent threads obtain access each to a dedicated unique slot allocated by the main object.
Since it’s uniquely assigned, each thread can and shall treat its assigned slot as its exclusive[*] property.
[*] There is an exception to the slot independency rule: under certain circumstances (maximum number of slots reached, timed events, user requests, etc) the main object (and all its slots) need to be handled as a whole, static thing. The main object is analysed and finally it is reset to the original empty state (i.e. all slots are discarded). During this analyse_and_reset process, access to the main object is exclusive.
So, in pseudo code (I’m still toying around with the design, so there is no actual code), the workers would work like:
W1. Obtain slot mutex (to guarantee unique allocation of slots)
W2. Get next available slot (from now own this thread is the absolute owner of the slot)
W3. Get a shared lock (communicate that work is being done on some slots - so analyze_and_reset must wait)
W4. Release slot mutex (let others tak their slot too)
W5. Operate on the slot in exclusive mode…
W6. Release shared lock (communicate that we are done operating on the slot - unblocks analyze_and_reset)
The analyze_and_reset code instead would look like this:
R1. Obtain slot mutex (to guarantee no further slot is assigned until we’re done with the reset, workers have to wait)
R2. Get an exclusive lock (wait till no more slots are being operated i.e. all workers are done with W5)
R3. Do business on the slots…
R4. Deallocate all the slots and reset the “next available slot” (i.e. reset the main object to its empty state)
R5. Release the exclusive lock (nothing really happens here since access to main object is still guarded by the mutex)
R6. Release the mutex (resume access to the main object)
The IRQL problem arises from the fact that W3 and W4 are “reversed”. However that is required in order to avoid that analyze_and_reset may discard a slot which is be
ing operated by a worker.
Hope that makes the picture clearer.
Thanks.
NTDEV is sponsored by OSR
Visit the list online at: http:
MONTHLY seminars on crash dump analysis, WDF, Windows internals and software drivers!
Details at http:
To unsubscribe, visit the List Server section of OSR Online at http:</http:></http:></http:>