Threads and Mutex

[Elisa]

Hi,

Imagine I have an app with 5 threads (A, B, C, D and E). They all need
access to the same method, MyMethod(), which has the following signature:

Public Sub MyMethod()
myMutex.WaitOne()
Try
' Do stuff here
Finally
myMutex.ReleaseMutex()
End Try
End Sub

When the app runs, a thread, let's say thread A, hits MyMethod() first,
and signals the Mutex. Now the other threads one by one hit MyMethod(),
let's say in order B, C, D and E, and block on the signaled Mutex.

My question is: do I have any guarantee that the Mutex will be released
to the threads, in the same order that the threads originally noticed
the signaled Mutex? Or do all threads have an equal change of reaching
the reseted Mutex first?

E.g. if the threads enter myMethod() in order A-E, will the threads step
through myMethod() in the same order?


Regards,

Elisa

 

[Chris Tacke, eMVP]

I don't believe you have any guarantee of the order in which subsequent
threads will get access to the method.

 

[Guest]

I think I am with Chris that there is no guarantee. However, I just played a little with a small test application in which I start a couple of threads, and every time the order in which threads start waiting for the mutex is also the order in which they continue running after the mutex is released. Thus, I think it is reasonably safe to say that the order of blocking is also the order of continuing. However, in a multithreaded system it might be hard to tell which will be the order in which the threads become waiting for the mutex

Regards
Maarten Struys, eMV
PTS Softwar
www.opennetcf.org | www.dotnetfordevices.co


----- Chris Tacke, eMVP wrote: ----

I don't believe you have any guarantee of the order in which subsequen
threads will get access to the method

 

[Elisa]

Hi,

I've just re-examined the MSDN Library documentation, I didn't find the
answer I was looking for re: Mutexes, but the Monitor class
documentation seems to say something about using wait queues. It's all a
bit obscure, but it leads me to believe that at least the Monitor class
queues threads in the order they hit the Monitor lock. And as a queue is
a FIFO structure, the logical conclussion would be to assume the Monitor
lock is handed out to the threads as they are stored in the queue, on a
first come, first served basis.

Still, I'm only guessing here, it would be nice if someone could give a
definitive answer...


Regards,

Elisa

 

[Jon Skeet [C# MVP]]

I've just re-examined the MSDN Library documentation, I didn't find the
answer I was looking for re: Mutexes, but the Monitor class
documentation seems to say something about using wait queues. It's all a
bit obscure, but it leads me to believe that at least the Monitor class
queues threads in the order they hit the Monitor lock. And as a queue is
a FIFO structure, the logical conclussion would be to assume the Monitor
lock is handed out to the threads as they are stored in the queue, on a
first come, first served basis.

Still, I'm only guessing here, it would be nice if someone could give a
definitive answer...

I wouldn't rely on extrapolations from Monitor (where Wait and Pulse
aren't even supported on the CF) to Mutex.

If you absolutely *require* this behaviour, I'd make sure of it
yourself rather than relying on the framework.

 

[Elisa]

Hi,

Well, I wasn't relying on extrapollation, I would simply use a Monitor
instead of a Mutex, if I'd be 100% certain that it would hand out the
Monitor lock on a first come first serve basis.

As an add-on, am I correct if I say that the Monitor class and the VB
SyncLock keyword are doing EXACTLY the same thing, or is there still a
difference between the two?


Regards,

Elisa

 

[Jon Skeet [C# MVP]]

Well, I wasn't relying on extrapollation, I would simply use a Monitor
instead of a Mutex, if I'd be 100% certain that it would hand out the
Monitor lock on a first come first serve basis.

You'd have no luck there, as Monitor.Wait and Pulse don't exist on the
compact framework. I've written a monitor "replacement" class to help,
but that then doesn't have the guarantees that the full framework
does...

As an add-on, am I correct if I say that the Monitor class and the VB
SyncLock keyword are doing EXACTLY the same thing, or is there still a
difference between the two?

SyncLock is just shorthand for using Monitor.Enter/Exit. I believe

SyncLock X
....
End SyncLock

is exactly equivalent to:

Monitor.Enter(X)
Try
...
Finally
Monitor.Exit(X)
End Try

(This is slightly different to the code given in the MSDN, because I
believe there's a documentation fault there: Monitor.Enter should come
before the Try, not after it. I've just mailed them about it.)

 

[Elisa]

Hi,

I'm not sure why the missing wait/pulse functionality should affect me.
As far as I understand it now, all three of the following should be more
ore less synonymous:

SyncLock X
...
End SyncLock


Monitor.Enter(X)
Try
...
Finally
Monitor.Exit(X)
End Try


myMutex.WaitOne()
Try
...
Finally
myMutex.ReleaseMutex()
End Try


The SyncLock and Monitor constructs are (according to our interpretation
of the documentation, no definitive answer yet) most likely handing out
the lock on a first-come first-serve basis, and, although the
documentation doesn't say anything about it, the Mutex construct seems
to behave the same way (cf. Maarten's experiment).


Regards,

Elisa

 

[Ginny Caughey [MVP]]

Elisa,

Probably you're right about only needing a SyncLock, but I'm not sure why
you would also need the Monitor in that case. And most of all, I'd be
concerned if your design requires multiple threads to do anything in any
particular order since that's not what they usually do.

 

[Guest]

I'm curious to see if they would execute in the same order if you increased the number of threads by an arbitrary number. Even if they did, there is no good reason to rely on something like this for computing unless you intend to stick to one device and os version. Very risky

----- Ginny Caughey [MVP] wrote: ----

Elisa

Probably you're right about only needing a SyncLock, but I'm not sure wh
you would also need the Monitor in that case. And most of all, I'd b
concerned if your design requires multiple threads to do anything in an
particular order since that's not what they usually do

 

[Dick Grier]

Hi,
As an add-on, am I correct if I say that the Monitor class and the VB
SyncLock keyword are doing EXACTLY the same thing, or is there still a
difference between the two?
<<

I use them equivalently. I suspect that there may be some underlying
difference. However, Monitor is much more limited on the Compact Framework
than it is on the desktop.

If it were my design, I would not make any assumptions about the sequence of
"events" (to use a misnomer here), after applying a lock and then releasing
it.

Dick

--
Richard Grier (Microsoft Visual Basic MVP)

See www.hardandsoftware.net for contact information.

Author of Visual Basic Programmer's Guide to Serial Communications, 3rd
Edition ISBN 1-890422-27-4 (391 pages) published February 2002.

 

[Ginny Caughey [MVP]]

Kevin,

They might one day, and then they might not some other time if other apps
were running or something. Threads are very unpredictable in my experience.
That's what makes them fun.
--
Ginny Caughey
..Net Compact Framework MVP

I'm curious to see if they would execute in the same order if you

increased the number of threads by an arbitrary number. Even if they did,
there is no good reason to rely on something like this for computing unless
you intend to stick to one device and os version. Very risky.

 

[Paul G. Tobey [eMVP]]

Exactly. You'll likely get different behavior in the debugger than without,
too. If you want thread B to follow thread A, start B from the end of A or
have a control thread that waits for A to end before launching B.

Paul T.