 |
 | Home | Contact Us | FAQ | Search & Site Map | Link to Us |
 | Sign In | Join | Other 45 Sites in Network |
.NET Forum / .NET Framework / CLR / June 2005FIFO mutex
Hi All, "Threads that are waiting for ownership of a mutex are placed in a first in, first out (FIFO) queue. Therefore, the first thread to wait on the mutex will be the first to receive ownership of the mutex, regardless of thread priority. However, kernel-mode APCs and events that suspend a thread will cause the system to remove the thread from the queue. When the thread resumes its wait for the mutex, it is placed at the end of the queue." http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dllproc/base/mu tex_objects.asp So Platform SDK documentation tells that mutex is not FIFO. Is it the same for the dotNET mutex? Does it mean that I need to make FIFO mutex myself? Aleksey. > Hi All, > [quoted text clipped - 13 lines] > > Aleksey. It clearly states that it's a FIFO.... "Threads that are waiting for ownership of a mutex are placed in a first in, first out (FIFO) queue. or is it the presence of APC's that makes you conclude this? .NET Mutex are wrappers around OS Mutant ojects so they behave the same, I really don't see how you could prevent the APC's to interfere when you would implement your own FIFO queue. Willy. >> "Threads that are waiting for ownership of a mutex are placed in a first >> in, first out (FIFO) queue. Therefore, the first thread to wait on the [quoted text clipped - 20 lines] > really don't see how you could prevent the APC's to interfere when you would > implement your own FIFO queue. I think about some class, which will include some mutex, event and queue inside. I just was wondering about something the same already included into the dotNET. Or some possibility to block the APC. Thank you for your answer. Aleksey. There is no way to block kernel APCs from user mode. If you need strict FIFO then I think the easiest approach is to give each thread its own event to wait on. Or may be you can redesign things so that infrequent violations of FIFO order can be handled gracefully. Generally speaking, strict FIFO order is rarely necessary or even desired. For example, critical sections before W2K3 SP1 had scalability problems under contention because they tried to maintain FIFO order (ignoring things like reordering due to kernel APCs). So now critical sections have been changedare no longer  SignatureThis posting is provided "AS IS" with no warranties, and confers no rights. >> .NET Mutex are wrappers around OS Mutant ojects so they behave the same, >> I really don't see how you could prevent the APC's to interfere when you [quoted text clipped - 5 lines] > dotNET. > Or some possibility to block the APC. > There is no way to block kernel APCs from user mode. > > If you need strict FIFO then I think the easiest approach is to > give each thread its own event to wait on. Or may be you can > redesign things so that infrequent violations of FIFO order can > be handled gracefully. Thanks, the queue of events looks like a good idea. :-) Aleksey. Hit send too early. Anyways, critical sections have been changed in W2K3 SP1 / XP x64 to allow non-FIFO order under contention. > There is no way to block kernel APCs from user mode. > [quoted text clipped - 18 lines] >> dotNET. >> Or some possibility to block the APC. I don't think this is strickly correct either. A "barging" thread that is ready to run could also run before all others in the "ready" queue IIRC. This is one reason why this case is accounted for in many queue designs that also wrap a lock/mutex. If you require forced FIFO, I would use your own queue. I have a blocking C# queue implementation on the CodeProject that you may find helpful. -- William Stacey [MVP] > Hi All, > [quoted text clipped - 13 lines] > > Aleksey. Hello William, How to find your implementation? Aleksey. >I don't think this is strickly correct either. A "barging" thread that is > ready to run could also run before all others in the "ready" queue IIRC. [quoted text clipped - 23 lines] >> >> Aleksey. Free MagazinesGet these publications absolutely FREE for up to 12 months. There are no hidden fees and no obligation. Simply choose a title, complete the application form and submit it. Read more ...
|
Reply to this Message
|
 Sign In
 Join
 My Latest Posts My Monitored Threads My Blog My Photo Gallery My Profile My Homepage Start New Thread Enable EMail Alerts Rate this Thread
|
©2008 Advenet LLC Privacy Policy - Terms of Use
This website includes both content owned or controlled by Advenet as well as content owned or controlled by third parties.