critical section vs mutex

134 views
Skip to first unread message

Jochen Wilhelmy

unread,
Nov 24, 2002, 8:20:09 PM11/24/02
to
please check if the following is correct:

if i want to lock some for access from multiple threads and
the lock is non-recursive and very short, then use
pthread_mutex_t for unix
CriticalSection for windows

if i want to have a long-term recursive mutex, then use
condition variables for unix
CreateMutex() for windows

has anybody a hint how to implement a long-term recursive mutex
for unix?

jochen

Alexander Terekhov

unread,
Nov 25, 2002, 2:30:06 AM11/25/02
to

Jochen Wilhelmy wrote:
>
> please check if the following is correct:
>
> if i want to lock some for access from multiple threads and
> the lock is non-recursive and very short, then use
> pthread_mutex_t for unix
> CriticalSection for windows

Uhmm. Why don't you try pthread_mutex_t for windows as well?

http://sources.redhat.com/pthreads-win32

>
> if i want to have a long-term recursive mutex, then use
> condition variables for unix
> CreateMutex() for windows
>
> has anybody a hint how to implement a long-term

long-term? Well, "long-term", you should better NOT use

> recursive mutex

at all. Well, as for "waiting, which is typically of long or unbounded
duration"...

<http://tinyurl.com/2s89> "Much experience with semaphores shows that ..."

> for unix?

Well ["short-term" -- to facilitate quick&dirty porting, etc.], standard
PTHREAD_MUTEX_RECURSIVE mutexes aside, you might want to take a look at:

http://groups.google.com/groups?threadm=3AE2EA20.1F38%40lycosmail.com
(Subject: About implementations of a recursive mutex)

regards,
alexander.

David Butenhof

unread,
Nov 25, 2002, 8:44:34 AM11/25/02
to
Jochen Wilhelmy wrote:

> please check if the following is correct:
>
> if i want to lock some for access from multiple threads and
> the lock is non-recursive and very short, then use
> pthread_mutex_t for unix
> CriticalSection for windows

Yes.

> if i want to have a long-term recursive mutex, then use
> condition variables for unix
> CreateMutex() for windows

A condition variable isn't a "mutex". Rather it's a SIGNALLING mechanism
that's ASSOCIATED with a mutex. You can't use a condition variable without
a mutex. That a thread might be waiting on a condition variable rather than
on the mutex itself doesn't mean the contention has less effect on
application concurrency and throughput.

You should NEVER hold a mutex for a long time, because when you do you
seriously degrade the application's ability to make use of threads. (In the
extreme case, you're often better off not using threads at all.)

> has anybody a hint how to implement a long-term recursive mutex
> for unix?

Never use recursive mutexes; they're inefficient hacks to avoid solving real
problems. Never hold mutexes for a long time, because mutexes prevent
concurrency or parallelism.

If you'd like advice on a specific synchronization problem, please describe
what you're doing and why.

--
/--------------------[ David.B...@hp.com ]--------------------\
| Hewlett-Packard Company Tru64 UNIX & VMS Thread Architect |
| My book: http://www.awl.com/cseng/titles/0-201-63392-2/ |
\----[ http://homepage.mac.com/dbutenhof/Threads/Threads.html ]---/

Jochen Wilhelmy

unread,
Nov 26, 2002, 7:24:55 AM11/26/02
to
> Never use recursive mutexes; they're inefficient hacks to avoid solving real
> problems. Never hold mutexes for a long time, because mutexes prevent
> concurrency or parallelism.


comparing win32 and pthread i wondered why win32 provides a critical
section (fast and non-recursive) and also a mutex (does a system-call
on lock in any case, therefore not so fast and recursive).
are there any real-world problems that need this kind of recursive
mutex?


> If you'd like advice on a specific synchronization problem, please describe
> what you're doing and why.

i only wanted do synchronize the shutdown of a process with multiple
threads, so it does not matter if the performance suffers. i now
solved this special problem with join (the way it is meant to
anyway). an interesting discovery: in the refcount-discussion
it became clear that refcounting is a kind of GC. starting
a thread creates an object that also should be managed by GC,
to remove the need to call pthread_detach() if you don't join it.
so i have a refcounted wrapper object for a thread that frees
the system resources in the destructor (calls pthread_detach()
if it was not joined, on windows CloseHandle()). so i can
a)
start a thread (refcount = 1) and don't care about it, when it
exits it removes a reference to the wrapper and the destructor is called
b)
start a thread and keep a reference (refcount = 2).
b1)
i call join(), the thread stops (refcount = 1), i release reference (delete)
b2)
i just release reference. either the thread has already stopped (delete)
or still runs (refcount = 1).


jochen

Jochen Wilhelmy

unread,
Nov 26, 2002, 7:57:03 AM11/26/02
to
> Uhmm. Why don't you try pthread_mutex_t for windows as well?
this is the "native" discussion. using pthread_mutex_t i would
have to include an extra library and critical section seems to
do what i want (as implementation of a c++ wrapper).

following your links i found that ACE has an implementation for
a recursive mutex that does what the windows-mutex does.

jochen

Alexander Terekhov

unread,
Nov 26, 2002, 8:13:05 AM11/26/02
to

Jochen Wilhelmy wrote:
[...]

>
> > Never use recursive mutexes; they're inefficient hacks to avoid solving real
> > problems. Never hold mutexes for a long time, because mutexes prevent
> > concurrency or parallelism.
>
> comparing win32 and pthread i wondered why win32 provides a critical
> section (fast and non-recursive)

Well, "fast" aside, it's surely recursive.

http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dllproc/base/critical_section_objects.asp

> and also a mutex (does a system-call
> on lock in any case, therefore not so fast and recursive).
> are there any real-world problems that need this kind of recursive
> mutex?

AFAICT, the only "real" problem is the quality of MS engineering.

[...]


> anyway). an interesting discovery: in the refcount-discussion
> it became clear that refcounting is a kind of GC. starting
> a thread creates an object that also should be managed by GC,
> to remove the need to call pthread_detach() if you don't join it.

Right.

> so i have a refcounted wrapper object for a thread that frees
> the system resources in the destructor (calls pthread_detach()

TSD-destructor? ;-)

> if it was not joined, on windows CloseHandle()). so i can
> a)
> start a thread (refcount = 1)

well, you should probably start it with 2.

> and don't care about it, when it
> exits it removes a reference to the wrapper and the destructor is called
> b)
> start a thread and keep a reference (refcount = 2).

Nah, 3.

> b1)
> i call join(), the thread stops (refcount = 1), i release reference (delete)
> b2)
> i just release reference. either the thread has already stopped (delete)
> or still runs (refcount = 1).

Yeah. http://www.terekhov.de/mythread.c

<code>

mt->eState = ( suspended ) ? MTS_START_SUSPENDED : MTS_START_RUNNING;
mt->ulRefCounter = ( NULL == pmt ) ? 2 : 3; // including TSD reference

if ( 0 != (status = pthread_create( &tid,
NULL,
&my_thread_start_routine,
&mts )) ) {
</code>

regards,
alexander.

Alexander Terekhov

unread,
Nov 26, 2002, 8:14:38 AM11/26/02
to

Jochen Wilhelmy wrote:
>
> > Uhmm. Why don't you try pthread_mutex_t for windows as well?

> this is the "native" discussion.

Yeah, I know. ;-) <http://tinyurl.com/30na>

> using pthread_mutex_t i would
> have to include an extra library and critical section seems to
> do what i want (as implementation of a c++ wrapper).

You should really join boost.org/Boost.Thread-developers, then.

> following your links i found that ACE has an implementation for
> a recursive mutex that does what the windows-mutex does.

Sure. ACE [and Boost.org] even has an implementation of "recursive"
condvar. ;-)

regards,
alexander.

Jochen Wilhelmy

unread,
Nov 26, 2002, 8:45:38 AM11/26/02
to
> Well, "fast" aside, it's surely recursive.
at least faster than mutex because they don't need a system
call if no other thread uses it (spin lock, for winxp
ready for the new hyperthreading cpu's),
and the recursive feature may be there but is not needed.

>>so i have a refcounted wrapper object for a thread that frees
>>the system resources in the destructor (calls pthread_detach()
>
>
> TSD-destructor? ;-)

what is TSD?


> well, you should probably start it with 2.

why?

> Nah, 3.
please explain :)

jochen

Alexander Terekhov

unread,
Nov 26, 2002, 11:53:04 AM11/26/02
to

Jochen Wilhelmy wrote:
[...]

> >>so i have a refcounted wrapper object for a thread that frees
> >>the system resources in the destructor (calls pthread_detach()
> >
> >
> > TSD-destructor? ;-)
> what is TSD?

Well, it's a sort of properly designed [but somewhat less convenient
for static usage] version of the {currently} broken gcc's TLS(*). ;-)

http://www.opengroup.org/onlinepubs/007904975/xrat/xsh_chap02.html#tag_03_02_09_03
(Thread-Specific Data)

http://www.opengroup.org/onlinepubs/007904975/basedefs/xbd_chap03.html#tag_03_397
(Thread-Specific Data Key)

> > well, you should probably start it with 2.
> why?
>
> > Nah, 3.
> please explain :)

http://www.terekhov.de/mythread.c

regards,
alexander.

(*) https://listman.redhat.com/pipermail/phil-list/2002-November/000322.html

GB

unread,
Nov 27, 2002, 3:16:41 AM11/27/02
to

"Jochen Wilhelmy" <j_D0T_w...@arcor.de> wrote in message
news:3DE36817...@arcor.de...

> comparing win32 and pthread i wondered why win32 provides a critical
> section (fast and non-recursive) and also a mutex (does a system-call
> on lock in any case, therefore not so fast and recursive).
> are there any real-world problems that need this kind of recursive
> mutex?

A critical section is a user-level object and thus limited to a single
process. Mutexes are kernel objects and can be used systemwide.

hth
GB


Alexander Terekhov

unread,
Nov 27, 2002, 4:07:41 AM11/27/02
to

GB wrote:
>
> "Jochen Wilhelmy" <j_D0T_w...@arcor.de> wrote in message
> news:3DE36817...@arcor.de...
> > comparing win32 and pthread i wondered why win32 provides a critical
> > section (fast and non-recursive) and also a mutex (does a system-call
> > on lock in any case, therefore not so fast and recursive).
> > are there any real-world problems that need this kind of recursive
> > mutex?
>
> A critical section is a user-level object and thus limited to a single
> process.

Yeah. Never mind that MS-critical-section's MS-event object is also
MS-kernel object just like MS-mutex.

> Mutexes are kernel objects and can be used systemwide.

Yeah. "can be used systemwide"... ``in a secure fashion!'' [thanks
to the attached MS-security-silliness, of course], right. ;-)

regards,
alexander.

Ziv Caspi

unread,
Nov 27, 2002, 9:03:20 AM11/27/02
to
On Wed, 27 Nov 2002 10:07:41 +0100, Alexander Terekhov
<tere...@web.de> wrote:

>
>GB wrote:
>>
>>
>> A critical section is a user-level object and thus limited to a single
>> process.
>
>Yeah. Never mind that MS-critical-section's MS-event object is also
>MS-kernel object just like MS-mutex.

What's your point? Acquiring a critical section does not go into
kernel mode unless there's a contention, that's why it's generally
more efficient than a mutex.

>> Mutexes are kernel objects and can be used systemwide.
>
>Yeah. "can be used systemwide"... ``in a secure fashion!'' [thanks
>to the attached MS-security-silliness, of course], right. ;-)

This is taking FUD to a new level. How does security enter the
equation (and why do you think it matters)?

Ziv

Jochen Wilhelmy

unread,
Nov 27, 2002, 9:06:51 AM11/27/02
to
> A critical section is a user-level object and thus limited to a single
> process. Mutexes are kernel objects and can be used systemwide.

is there a possibility to get a system wide mutex in posix?

jochen

David Butenhof

unread,
Nov 27, 2002, 10:27:57 AM11/27/02
to
Jochen Wilhelmy wrote:

You can initialize a pthread_mutex_t object that's allocated in a shared
memory region, using an attributes object with the "pshared" attribute set
to POSIX_PROCESS_SHARED. That object can then be used for synchronization
by any active entity on the system (thread or "process") with access to
that memory.

This is an OPTION of POSIX, though required by the Single UNIX
Specification, Version 2. I believe that the current LinuxThreads doesn't
support it, and I doubt that the win32-pthreads supports it. I believe that
Ulrich Drepper's forthcoming replacement for the current LinuxThreads WILL
support it.

Alexander Terekhov

unread,
Nov 27, 2002, 10:34:16 AM11/27/02
to

Ziv Caspi wrote:
>
> On Wed, 27 Nov 2002 10:07:41 +0100, Alexander Terekhov
> <tere...@web.de> wrote:
>
> >
> >GB wrote:
> >>
> >>
> >> A critical section is a user-level object and thus limited to a single
> >> process.
> >
> >Yeah. Never mind that MS-critical-section's MS-event object is also
> >MS-kernel object just like MS-mutex.
>
> What's your point?

Follow the links below.

> Acquiring a critical section does not go into
> kernel mode unless there's a contention, that's why it's generally
> more efficient than a mutex.

^^^^^^^^^^^^

than *MS* mutex. And as for "generally"... take this(N2):

http://groups.google.com/groups?threadm=3CC92ABF.D17AC3A2%40web.de
http://groups.google.com/groups?threadm=3CCADCF0.F8D5D840%40web.de
http://groups.google.com/groups?threadm=3CCD5ADE.A164B4A0%40web.de
(Heck, "Subject: Re: mutex or critical section")

> >> Mutexes are kernel objects and can be used systemwide.
> >
> >Yeah. "can be used systemwide"... ``in a secure fashion!'' [thanks
> >to the attached MS-security-silliness, of course], right. ;-)
>
> This is taking FUD to a new level.

Thanks.

> How does security enter the equation (and why do you think it matters)?

Yeah. That's rather interesting question. How can that silly MS-
mutex-"security"-stuff help you to "secure" the >>shared data<<
associated with mutex? What is it good for?

regards,
alexander.

Norman Black

unread,
Nov 27, 2002, 4:00:36 PM11/27/02
to
> How can that silly MS-
> mutex-"security"-stuff help you to "secure" the >>shared data<<
> associated with mutex?
>What is it good for?

Anyone knowing the name of a system shared entity can open it an use it.
The security provisions allow you to restrict this access to users with
appropriate access rights.

--
Norman Black
Stony Brook Software
nospam => stonybrk

"Alexander Terekhov" <tere...@web.de> wrote in message
news:3DE4E5F8...@web.de...

Jochen Wilhelmy

unread,
Nov 27, 2002, 6:17:35 PM11/27/02
to
i now have found out these differences between critical section and
mutex. i will call it Mutex and RecursiveMutex (have better names? :))
and have therefore 2 classes now

Mutex:
- as fast as possible (members are inline that the
wrapper causes less overhead
- lock() is not a cancellation point
- trylock() does not support a timeout
- unix: pthread_mutex_t, windows: criticalSection
(if this is braindead please tell me a solution
that is faster, some comparison chart to pthread/win32 or so)

RecursiveMutex:
- speed is not the primary goal
- lock() is a cancellation point and recursive
(my wrappers don't support cancellation yet)
- trylock() also supports a timeout
- can be system wide (at least for windows now, my wrappers
don't support it yet)
- unix: mutex combined with condition var, windows: mutex


jochen

Pavel Lebedinsky

unread,
Nov 27, 2002, 6:30:47 PM11/27/02
to
"Alexander Terekhov" <tere...@web.de> wrote:

> > >Yeah. "can be used systemwide"... ``in a secure
> > > fashion!'' [thanks to the attached MS-security-
> > > silliness, of course], right. ;-)

They can also be used systemwide without "attached
silliness", thanks to DuplicateHandle and handle
inheritance.

> > How does security enter the equation (and why do
> > you think it matters)?
>
> Yeah. That's rather interesting question. How can

> that silly MS-mutex-"security"-stuff help you to


> "secure" the >>shared data<< associated with
> mutex? What is it good for?

Let's say I want to serialize access to a file from
several processes. I can use a named mutex for
this. The "shared data" (the file) can be protected
using normal file system ACLs.

Not that I think that this design is ideal but
sometimes it can be useful.


Jochen Wilhelmy

unread,
Nov 27, 2002, 6:37:17 PM11/27/02
to
> Well, it's a sort of properly designed [but somewhat less convenient
> for static usage] version of the {currently} broken gcc's TLS(*). ;-)
ah, TSD = thread specific data, i knew only TLS = thread local storage.
are there other methods than pthread_key_create? something in glibc?

i used a global map<pthread_t, SmartPoiter<MyThread> > for it.
that's surely not the best solution for storing the data associated
with a thread.
but for making TSD available for c++ it is the only solution that
has no system limits. i have a ThreadData template and you can
have a ThreadData<int> in a class and instantiate this class
thousands of times, each instance having its thread local int.
currently the global mutex for accessing the map is a bottleneck,
a map that is threadsafe on element basis would be needed.

jochen

Alexander Terekhov

unread,
Nov 28, 2002, 4:32:08 AM11/28/02
to

Norman Black wrote:
>
> > How can that silly MS-
> > mutex-"security"-stuff help you to "secure" the >>shared data<<
> > associated with mutex?
> >What is it good for?
>
> Anyone knowing the name of a system shared entity can open it an use it.

Without having access to shared data in *memory* that is supposed to be
associated with *mutex*? ... Oh, yeah, sure:

http://groups.google.com/groups?selm=3a608105%241%40news.starhub.net.sg
(Subject: [NEWS] Trojans can block ZoneAlarm by setting a Mutex in memory)

I especially like this: <quote> Zone Labs "ZoneAlarm" and "ZoneAlarm Pro"
programs both use a Mutex - an event synchronization memory object</quote>.
^^*^^^^^*^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
*****

> The security provisions allow you to restrict this access to users with
> appropriate access rights.

Again: what is it [i.e. security provisions attached to a *mutex*] good for?
(Trojans aside for a moment ;-) ;-) )

regards,
alexander.

Alexander Terekhov

unread,
Nov 28, 2002, 4:33:52 AM11/28/02
to

Pavel Lebedinsky wrote:
>
> "Alexander Terekhov" <tere...@web.de> wrote:
>
> > > >Yeah. "can be used systemwide"... ``in a secure
> > > > fashion!'' [thanks to the attached MS-security-
> > > > silliness, of course], right. ;-)
>
> They can also be used systemwide without "attached
> silliness", thanks to DuplicateHandle and handle
> inheritance.

Brain-dead MS-"handlers"-all-over-again aside for a moment,
that isn't "systemwide", Pavel.

> > > How does security enter the equation (and why do
> > > you think it matters)?
> >
> > Yeah. That's rather interesting question. How can
> > that silly MS-mutex-"security"-stuff help you to
> > "secure" the >>shared data<< associated with
> > mutex? What is it good for?
>
> Let's say I want to serialize access to a file from

> several processes. ....

http://msdn.microsoft.com/library/default.asp?url=/library/en-us/fileio/base/locking_and_unlocking_byte_ranges_in_files.asp

regards,
alexander.

Jochen Wilhelmy

unread,
Nov 28, 2002, 5:47:30 AM11/28/02
to
i forgot an important difference:

Mutex is short term,
RecursiveMutex is long term lockable

jochen

Alexander Terekhov

unread,
Nov 28, 2002, 6:39:02 AM11/28/02
to

Jochen Wilhelmy wrote:
>
> i forgot an important difference:
>
> Mutex is short term,

Right.

> RecursiveMutex is long term lockable

No.

Semaphore is long term lockable/waitable and is really good
if/when you *don't* share memory.

Condvar is long term waitable.

And RecursiveMutex is most often simply "brain-dead" [just like
MS-events; but they're almost ALWAYS "brain-dead"].

regards,
alexander.

Jochen Wilhelmy

unread,
Nov 28, 2002, 7:50:10 AM11/28/02
to
>>RecursiveMutex is long term lockable
>
>
> No.
>
> Semaphore is long term lockable/waitable and is really good
> if/when you *don't* share memory.
why not? i have specified it as long term lockable
and implemented it that it is long term lockable
on unix (with condvar) and windows (the brain dead mutex).
a recursive mutex on unix that is supposed to be
cancellable has to be implemented with a condvar and
therefore it is automatically long term lockable.

> And RecursiveMutex is most often simply "brain-dead" [just like
> MS-events; but they're almost ALWAYS "brain-dead"].

i have done it for the brain dead coders just like
goto is in c++ for the brain dead coders
(perhaps i write in the documentation: if you use
this you are brain dead :) )

but how would you implement this problem properly:
one thread allocates a certain object 0 to n times.
another thread has to wait somewhere as long as
at least one of such object exists. this can
easily be done with a long term lockable recursive
mutex (lock in the constructor, unlock in the destructor
of the object). of course it can be done with a condvar
but the recursive mutex also uses a condvar.
and windows, yes this is surely brain dead,
has no proper support for condvars (at best
since the newer versions)

jochen

Alexander Terekhov

unread,
Nov 28, 2002, 9:10:14 AM11/28/02
to

Jochen Wilhelmy wrote:
[...]

> a recursive mutex on unix that is supposed to be
> cancellable has ....

POSIX/UNIX's PTHREAD_MUTEX_RECURSIVE mutex is >>NOT<<
supposed to be cancelable:

http://www.opengroup.org/onlinepubs/007904975/functions/xsh_chap02_09.html#tag_02_09_05_02
(Cancelation Points)

> i have done it for the brain dead coders just like
> goto is in c++ for the brain dead coders

BTW, rather interesting reading on the history of ``goto is
brain-dead'' (so to speak) and etc. ("Structured" stuff):

http://groups.google.com/groups?selm=3DD8BD8B.3920EE0F%40web.de
(Subject: Re: [OT-ish] goto and dijkstra)

> (perhaps i write in the documentation: if you use
> this you are brain dead :) )

Right. ;-)

> but how would you implement this problem properly:
> one thread allocates a certain object 0 to n times.

"allocates" == "designates" (i.e./my-friend-Dictionary-
says: "to make known or identify"), I'll presume.



> another thread has to wait somewhere as long as
> at least one of such object exists.

^^^^^^^^^^^^^^^^^^^^^^^^^

Uhmm, but you've said: "certain object 0 to n times". So,
there should be just ONE SINGLE object that OPTIONAL/CAN
be designated multiple times by multiple threads and that
SHALL NOT exist until someone decides to designate it,
right?

> this can easily be done with a long term lockable
> recursive mutex (lock in the constructor, unlock
> in the destructor of the object).

Now ``I'm lost.'' If what you need is simply non-static
LAZY init, then just do it this way (a bit surprising,
but you can easily do it on Windows [see links in the
2nd message below] thanks to [/despite] its totally
brain-dead sort-of-TSD and utterly brain-dead named and
"secure" mutexes... you'll have to wait just-a-couple-of
years for the POSIX version of "dynamic-pthread_once()",
I'm afraid ;-) ):

http://www.opengroup.org/austin/mailarchives/austin-group-l/msg04858.html
http://www.opengroup.org/austin/mailarchives/austin-group-l/msg04852.html
(Subject: Re: interaction of pthread_once() and longjmp())

regards,
alexander.

Jochen Wilhelmy

unread,
Nov 28, 2002, 4:07:54 PM11/28/02
to
> POSIX/UNIX's PTHREAD_MUTEX_RECURSIVE mutex is >>NOT<<
> supposed to be cancelable:
>
> http://www.opengroup.org/onlinepubs/007904975/functions/xsh_chap02_09.html#tag_02_09_05_02
> (Cancelation Points)

yes i know that but my own thing that i call RecursiveMutex
is a thing that behaves equal on unix and windows and
is long-term lockable and cancelable. the thing that i call
Mutex corresponds to a pthread_mutex_t and is not specified
to be recursive since not all platforms support
PTHREAD_MUTEX_RECURSIVE and making the "normal" mutex recursive
causes too much overhead.

i just wanted to point out that a "mutex" can have two different
flavours (fast - not optimized on speed, not/sometimes recursive
- always recursive, not cancellable - cancellable, trylock without
timeout - with timeout)
if you want to, call it Mutex and BrainDeadThing :)

>>but how would you implement this problem properly:
>>one thread allocates a certain object 0 to n times.
>
> "allocates" == "designates" (i.e./my-friend-Dictionary-
> says: "to make known or identify"), I'll presume.

"allocates" = "new SomeObject()"

> Uhmm, but you've said: "certain object 0 to n times". So,
> there should be just ONE SINGLE object that OPTIONAL/CAN
> be designated multiple times by multiple threads and that
> SHALL NOT exist until someone decides to designate it,
> right?

sounds not so right. one thread allocates objects with
new and deletes them with delete. so at a certain time
there are 0 to n objects allocated on the heap. another
thread may pass a certain point only if there are 0
ojbects currently allocated.

jochen

Alexander Terekhov

unread,
Nov 29, 2002, 4:27:57 AM11/29/02
to

Jochen Wilhelmy wrote:
[...]

> i just wanted to point out that a "mutex" can have two different
> flavours (fast - not optimized on speed, not/sometimes recursive
> - always recursive, not cancellable - cancellable, trylock without
> timeout - with timeout)

Well, ``okay,'' but "trylock without timeout - with timeout" is
actually known as _trylock()/_timedlock(), BTW.

http://www.opengroup.org/onlinepubs/007904975/functions/pthread_mutex_trylock.html
http://www.opengroup.org/onlinepubs/007904975/functions/pthread_mutex_timedlock.html

Uhmm, y'know, as I've mentioned already, you should really take a look
Boost.Thread -- at the "zillion+1" of Boost.Thread's "mutex concepts"
("models"/classes/whatever) in this case. You'll surely really like it.

http://www.boost.org/libs/thread/doc/mutex.html
http://www.boost.org/libs/thread/doc/mutex.html#class-mutex-synopsis
http://www.boost.org/libs/thread/doc/mutex.html#class-try_mutex
http://www.boost.org/libs/thread/doc/mutex.html#class-timed_mutex
http://www.boost.org/libs/thread/doc/recursive_mutex.html#class-recursive_mutex
http://www.boost.org/libs/thread/doc/recursive_mutex.html#class-recursive_try_mutex
http://www.boost.org/libs/thread/doc/recursive_mutex.html#class-recursive_timed_mutex

> if you want to, call it Mutex and BrainDeadThing :)

Yep, that's the right name.

> >>but how would you implement this problem properly:
> >>one thread allocates a certain object 0 to n times.
> >
> > "allocates" == "designates" (i.e./my-friend-Dictionary-
> > says: "to make known or identify"), I'll presume.
> "allocates" = "new SomeObject()"

Ah. Okay.

>
> > Uhmm, but you've said: "certain object 0 to n times". So,
> > there should be just ONE SINGLE object that OPTIONAL/CAN
> > be designated multiple times by multiple threads and that
> > SHALL NOT exist until someone decides to designate it,
> > right?
> sounds not so right. one thread allocates objects with
> new and deletes them with delete. so at a certain time
> there are 0 to n objects allocated on the heap. another
> thread may pass a certain point only if there are 0
> ojbects currently allocated.

Yeah. I'm sure you've made it up quickly to "justify" the
inclusion/creation of the BrainDeadThing(TM), oder? ;-)

I'm just curious: is THIS really THE THING you're after?

regards,
alexander.

Jochen Wilhelmy

unread,
Nov 29, 2002, 5:51:31 AM11/29/02
to
i'll have a look at it.

> Yeah. I'm sure you've made it up quickly to "justify" the
> inclusion/creation of the BrainDeadThing(TM), oder? ;-)
>
> I'm just curious: is THIS really THE THING you're after?

no, this at first was a real scenario (the objects to be
created are audio streams and the main thread may only
proceed to shut down if all audio streams are gone)
but join() was a better idea :)

jochen

Ziv Caspi

unread,
Dec 1, 2002, 3:13:41 PM12/1/02
to
On Wed, 27 Nov 2002 16:34:16 +0100, Alexander Terekhov
<tere...@web.de> wrote:

>> Acquiring a critical section does not go into
>> kernel mode unless there's a contention, that's why it's generally
>> more efficient than a mutex.
> ^^^^^^^^^^^^
>
>than *MS* mutex.

Than mutex. Are there any other mutex implementations over Win32 that
you're aware of?

What part of "unless there's a contention" didn't you understand?

Would it surprise you to learn that different mechanisms behave
differently under different loads? Quick: Is it better to poll for
events or use interrupts?

>http://groups.google.com/groups?threadm=3CCD5ADE.A164B4A0%40web.de
>(Heck, "Subject: Re: mutex or critical section")

So ZoneAlarms had a security bug. Imagine my surprise.

>> How does security enter the equation (and why do you think it matters)?
>
>Yeah. That's rather interesting question. How can that silly MS-
>mutex-"security"-stuff help you to "secure" the >>shared data<<
>associated with mutex?

Obviously, it can't, and was never intended to.

> What is it good for?

(tongut-in-cheek) To deny access to processes that attempt to open a
mutex you own but don't want to share.

Seriously, a mutex is a named kernel object. To be able to access it
from different processes you need handle inheritence, handle
duplication, or named creation. All these are provided by the same
kernel-mode component that does security checks (and for good reason).
There's simply no reason *not* to expose this functionality to users.

Ziv

Alexander Terekhov

unread,
Dec 2, 2002, 4:38:50 AM12/2/02
to

Ziv Caspi wrote:
[...]

> Seriously, a mutex is a named kernel object.

Why the heck is MS-mutex "a named kernel object"... and *NOT* simply
"a memory object" like POSIX's pthread_mutex_t?

What is it [i.e. MS-mutex's characteristics of "named kernel object"
good for?

regards,
alexander.

David Butenhof

unread,
Dec 2, 2002, 9:41:48 AM12/2/02
to
Jochen Wilhelmy wrote:

I'd still like to know exactly what distinction you think the term "long
term lockable" should convey?

There is no inherent time limit for locking a mutex. (As usual, Mr Phelps,
this mutex will unlock itself in 30 seconds.) You're ALLOWED to lock a
mutex on entry to main() and retain ownership until the program terminates.
It would be pointless, but it's legal. So the only meaningful distinction I
can imagine for the term "long term lockable" might be that it refers to an
object with persistent state, that will last beyond the life of the
process. (Note that a pshared POSIX mutex satisfies that definition. And,
in any case, I could think of several much more appropriate names than
"long term lockable", including simply "persistent".)

Regardless of the implementation of the mutex, though, holding the lock for
an extended period of time (any longer than strictly necessary to protect
shared data invariants) is foolish. A mutex is a BOTTLENECK, the eye of a
needle through which all threads must, one at a time, pass. If you hold a
mutex that's not contended, then the lock doesn't affect application
parallelism or throughput... but it doesn't do anyone any good, either. If
there IS contention, then you reduce concurrency as a direct function of
the length you hold the resource and the number of threads contending for
it. In the extreme, as in a mutex held by a common event loop executed
frequently by all threads, you'll often get better performance by running
with a single thread. (Note: one often hears complaints that "I ran my code
on a multiprocessor and it got slower!" Well, "long term locking" is one of
the more common causes for this complaint.)

A "long term lockable mutex" either is never used for the purpose suggested
by the name, or is a really bad idea that's pulling the whole application
down with it. In either case, stick with a simple mutex, and design your
code to lock it infrequently and for short periods of time.

Ziv Caspi

unread,
Dec 2, 2002, 3:42:33 PM12/2/02
to
On Mon, 02 Dec 2002 10:38:50 +0100, Alexander Terekhov
<tere...@web.de> wrote:

>
>Ziv Caspi wrote:
>[...]
>> Seriously, a mutex is a named kernel object.
>
>Why the heck is MS-mutex "a named kernel object"... and *NOT* simply
>"a memory object" like POSIX's pthread_mutex_t?

So that you could use it to do cross-process synchronization without
the need for a (wasteful) memory mapping.

>What is it [i.e. MS-mutex's characteristics of "named kernel object"
>good for?

See above.

Ziv

Pavel Lebedinsky

unread,
Dec 2, 2002, 10:05:33 PM12/2/02
to
"Alexander Terekhov" wrote:

> > > > >Yeah. "can be used systemwide"... ``in a secure
> > > > > fashion!'' [thanks to the attached MS-security-
> > > > > silliness, of course], right. ;-)
> >
> > They can also be used systemwide without "attached
> > silliness", thanks to DuplicateHandle and handle
> > inheritance.
>
> Brain-dead MS-"handlers"-all-over-again aside for a moment,
> that isn't "systemwide", Pavel.

Why isn't it systemwide? Given enough rights you can duplicate
handles from/to any process in the system.

(My point was actually that "security silliness" is "attached"
only to named mutexes. Mutexes that don't have names can't
be opened by name, so they don't need security descriptors.
They can still be useful nevertheless.)

> > > > How does security enter the equation (and why do
> > > > you think it matters)?
> > >
> > > Yeah. That's rather interesting question. How can
> > > that silly MS-mutex-"security"-stuff help you to
> > > "secure" the >>shared data<< associated with
> > > mutex? What is it good for?
> >
> > Let's say I want to serialize access to a file from
> > several processes. ....
>
>
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/fileio/base
/locking_and_unlocking_byte_ranges_in_files.asp

1. LockFile doesn't allow me to wait until the file is available,
so I'd have to poll. Mutex is more convenient.

2. What if I need to update several files at once?

Anyways, I used files simply as an example. There are other
types of resources that can be protected independently.


Alexander Terekhov

unread,
Dec 3, 2002, 4:12:07 AM12/3/02
to

Pavel Lebedinsky wrote:
[...]

> 1. LockFile doesn't allow me to wait until the file is available,
> so I'd have to poll. Mutex is more convenient.
>
> 2. What if I need to update several files at once?
>
> Anyways, I used files simply as an example. There are other
> types of resources that can be protected independently.

On a non-bread-dead systems, you're supposed to use POSIX mutexes
and condvars to build whatever sync. protocols you might need/like.
In POSIX, mutexes and condvars are just "memory objects". It works
perfectly [problems with emulating PROCESS_SHARED ones on Win32
aside]. MS-handles-all-over-again-for-everything is BRAIN-DEAD.
Period.

regards,
alexander.

Alexander Terekhov

unread,
Dec 3, 2002, 4:17:54 AM12/3/02
to

See below.

http://www.opengroup.org/onlinepubs/007904975/xrat/xsh_chap02.html#tag_03_02_09
(Threads)

"....
Mutexes and condition variables are specified as synchronization
mechanisms between threads; these threads always share (some)
memory. Both are synchronization paradigms that have been in
widespread use for a number of years.
....
Counting semaphores are well matched to dealing with producer/
consumer problems, including those that might exist between
threads of different processes, or between a signal handler
and a thread. In the former case, there may be little or no
memory shared by the processes; in the latter case, one is not
communicating between co-equal threads, but between a thread
and an interrupt-like entity. It is for these reasons that IEEE
Std 1003.1-2001 allows semaphores to be used by threads.
....
Mutexes and condition variables together constitute an
appropriate, sufficient, and complete set of inter-thread
synchronization primitives.
...."

regards,
alexander.

David Schwartz

unread,
Dec 3, 2002, 1:15:02 PM12/3/02
to
Alexander Terekhov wrote:

> MS-handles-all-over-again-for-everything is BRAIN-DEAD.
> Period.

The same argument could be made, equally pointlessly, about UNIX's
files-all-over-again-for-everything.

DS

Alexander Terekhov

unread,
Dec 3, 2002, 1:36:33 PM12/3/02
to

I don't follow your logic. Care to elaborate? TIA.

regards,
alexander.

Ziv Caspi

unread,
Dec 3, 2002, 3:47:47 PM12/3/02
to

I fail to see your point. You quote a spec of a different threading
model than Win32 that indicates mutexes are useful and then ask why
Win32 mutexes are useful?

BTW, there's another reason why named objects are useful even
intra-process: you don't have to pass information between different
components in the process to synchronize. Just knowing the name of the
synchronization element is sufficient.

Ziv

Alexander Terekhov

unread,
Dec 4, 2002, 4:58:01 AM12/4/02
to

The point is that MS "mut..."-thing isn't really useful [except for the
"DCI" hack that creates/opens/destroys the named mutex just to get rid
of it ASAP] because it is nothing but a silly [kinda innovative-beyond-
the-limits, if you like] mut...*ant*, ``so to speak.''

regards,
alexander.

--
"VMS + 1 = WNT (HAL + 1 = IBM)" < .... > "The name /mutant/ has a
colorful [sic] history. Early in Windows NT's development, Dave
Cutler created a kernel mutex object that implemented low-level
mutual exclusion. Later he discovered that OS/2 required a version
of the mutual-exclusion semaphore with additional semantics,
which Dave considered "brain-damaged" and which was incompatible
with the original object. (Specifically, a thread could abandon
the object and leave it inaccessible.) So he created an OS/2
version of the mutex and gave it the name /mutant/. Later Dave
modified the mutant object to remove the OS/2 semantics, allowing
the Win32 subsystem to use the object. The Win32 API calls the
modified object /mutex/, but the native services retain the name
/mutant/." -- google

Jochen Wilhelmy

unread,
Dec 4, 2002, 8:09:04 AM12/4/02
to
> I'd still like to know exactly what distinction you think the term "long
> term lockable" should convey?
i would say "long term lockable" means that a thread waiting on it
consumes no processor time (no busy waiting which is sometimes
done for "fast mutexes", but often the busy waiting stops after
a spin count)

i also would say that "persistent" is a good feature of this
object (this mutex, but perhaps we should not call it mutex
to get out of the discussion if it is brain dead or not)
i now call it SystemMutex because it is a system wide mutex
(but a still better name not containing "mutex" should be found).
in some way it is used as a semaphore to signal other processes
the presence or absence of some stuff (for example if an app
is already running) and not for data locking.

by the way: can condition vars also exist system wide?


jochen

Jochen Wilhelmy

unread,
Dec 4, 2002, 8:22:10 AM12/4/02
to
> Mutexes and condition variables together constitute an
> appropriate, sufficient, and complete set of inter-thread
> synchronization primitives.


but we search for inter-process synchronisation.

the reason why the windows mutex is brain dead is because
it is a system object. are cond-vars not system objects?
the system has to put it into a queue for waiting, but
does not have to create a system object?

jochen

Joseph Seigh

unread,
Dec 4, 2002, 8:50:09 AM12/4/02
to

Unix ipc semaphores would be a closer equivalent. You're
correct that posix library routines resort to kernel objects
in some cases.

The key characteristics would be that system objects have better
integrity. You can't do things like accidentally delete them
with processes/threads blocked. Memory objects usually have
much better performance. It's a trade off.

And one other thing. System objects can sync more than just
memory state/visibility. Stuff like filesytems.

An interesting exercise. Try writing an application that
accesses files via filesytem calls *and* memory mapped files,
and try to keep everything in sync and consistent. It's
not trivial.

Joe Seigh

David Butenhof

unread,
Dec 5, 2002, 3:22:07 PM12/5/02
to
Jochen Wilhelmy wrote:

>> I'd still like to know exactly what distinction you think the term "long
>> term lockable" should convey?
> i would say "long term lockable" means that a thread waiting on it
> consumes no processor time (no busy waiting which is sometimes
> done for "fast mutexes", but often the busy waiting stops after
> a spin count)

There's no reason that a condition variable can't spinwait, too. Just as a
mutex owner might "be just about to unlock", someone manipulating the
shared data might be "just about to signal or broadcast".

Now, the mutex associated with the share data (and condition variable) must
have been locked "just an instant ago" when the caller entered
pthread_cond_[timed]wait, limiting the chances for some other thread to
satisfy the predicate. (It can't have already been satisfied, or we
wouldn't be waiting.) Still, if the synchronization is fine-grained enough
it's quite possible that some other thread will lock the mutex IMMEDIATELY
when the waiter releases it, "do its business", and get out quickly. If
that happens often enough, a spin could be well worthwhile.

The critical question is, of course, how often that happens and what is the
cost of spinning to applications that will always block. Still, I'm not
saying one SHOULD do this, only that there's no reason some implementation
COULDN'T do this, and it might even be a big payoff for some application
loads.

So... don't ever ASSUME that it can't be done that way. ;-)

> i also would say that "persistent" is a good feature of this

> object [...]


>
> by the way: can condition vars also exist system wide?

Of course; POSIX allows process-shared mutexes and condition variables. (And
read-write locks.)

Ziv Caspi

unread,
Dec 5, 2002, 5:07:26 PM12/5/02
to
On Wed, 04 Dec 2002 10:58:01 +0100, Alexander Terekhov
<tere...@web.de> wrote:

>
>Ziv Caspi wrote:
>> I fail to see your point.
>
>The point is that MS "mut..."-thing isn't really useful [except for the
>"DCI" hack that creates/opens/destroys the named mutex just to get rid
>of it ASAP] because it is nothing but a silly [kinda innovative-beyond-
>the-limits, if you like] mut...*ant*, ``so to speak.''

Name calling is not an argument. A mutex is quite useful for, say,
allowing one process to write a few values to a registry key while
another process waits for it to be done. One may construct many such
examples.

Ziv

Hillel Y. Sims

unread,
Dec 5, 2002, 5:39:30 PM12/5/02
to
"David Butenhof" <David.B...@hp.com> wrote in message
news:mnOH9.6$VN5.8...@news.cpqcorp.net...

>
> There's no reason that a condition variable can't spinwait, too. Just as a
> mutex owner might "be just about to unlock", someone manipulating the
> shared data might be "just about to signal or broadcast".
>
[..]

>
> The critical question is, of course, how often that happens and what is
the
> cost of spinning to applications that will always block. Still, I'm not
> saying one SHOULD do this, only that there's no reason some implementation
> COULDN'T do this, and it might even be a big payoff for some application
> loads.
>
> So... don't ever ASSUME that it can't be done that way. ;-)

kind of like half a dozen or so retries before sleeping, on a
multiprocessor? does VMS do this? can (does?) the implementation switch in
different versions of the library based on whether the exe's
multiple-kernel-threads flag is enabled/disabled (eg, on VMS)?

hys

--
(c) 2002 Hillel Y. Sims
FactSet Research Systems
hsims AT factset.com


Alexander Terekhov

unread,
Dec 6, 2002, 5:43:13 AM12/6/02
to
> examples. ^^^^^(sigh)

Sure. One may construct infinite number of brain-dead things [such as
MS-mutant-aka-MS-mutex]. Well, name calling aside, I guess, it's time
for you to fire a search on "mutex fairness" [or just ask Pavel ;-)].
You may also want to take a look at what The Inventor [well, sort-of]
of the "mutual exclusion" wrote about it [in the 1960s or early 1970s,
IIRC] -- see <http://www.amazon.com/exec/obidos/ASIN/0387954015>...

regards,
alexander.

David Butenhof

unread,
Dec 6, 2002, 8:00:59 AM12/6/02
to
Hillel Y. Sims wrote:

No, we DON'T do this, though I've considered it. The problem, as I said, is
that it's hard to determine whether spinning will be a win. It's usually a
win (on a multiprocessor) to spin on a mutex, because correctly coded
applications will hold a mutex infrequently and for short periods and are
therefore likely to avoid blocking fairly often. The case with condition
variables is substantially less clear (or general) because the optimization
will help only for fairly specific application loads. (The "producer" of
the predicate needs to acquire the mutex, change the data, release the
mutex, and signal the condition variable during the "consumer's" spinwait;
so either that has to all happen really fast, or the spin has to be so long
that you'll waste more time than you save.)

Our implementation does spin on mutex locks, and only on a multiprocessor.
(On VMS, for all practical purposes, an application linked without enabling
multiple kernel threads is NEVER running on a multiprocessor, so it won't
spin.)

Hillel Y. Sims

unread,
Dec 6, 2002, 10:15:33 AM12/6/02
to

"David Butenhof" <David.B...@hp.com> wrote in message
news:O%0I9.12$Xh6.2...@news.cpqcorp.net...

> No, we DON'T do this, though I've considered it. The problem, as I said,
is
> that it's hard to determine whether spinning will be a win. It's usually a
> win (on a multiprocessor) to spin on a mutex, because correctly coded
> applications will hold a mutex infrequently and for short periods and are
> therefore likely to avoid blocking fairly often. The case with condition
> variables is substantially less clear (or general) because the
optimization
> will help only for fairly specific application loads. (The "producer" of
> the predicate needs to acquire the mutex, change the data, release the
> mutex, and signal the condition variable during the "consumer's" spinwait;
> so either that has to all happen really fast, or the spin has to be so
long
> that you'll waste more time than you save.)
>

ah, I see what you mean..

> Our implementation does spin on mutex locks, and only on a multiprocessor.
> (On VMS, for all practical purposes, an application linked without
enabling
> multiple kernel threads is NEVER running on a multiprocessor, so it won't
> spin.)

<austin powers>very randy!

Ziv Caspi

unread,
Dec 6, 2002, 6:03:22 PM12/6/02
to
On Fri, 06 Dec 2002 11:43:13 +0100, Alexander Terekhov
<tere...@web.de> wrote:

>Sure. One may construct infinite number of brain-dead things [such as
>MS-mutant-aka-MS-mutex]. Well, name calling aside, I guess, it's time
>for you to fire a search on "mutex fairness" [or just ask Pavel ;-)].

Google search gives >2000 results. Surely a better pointer could prove
useful?

Searching this group did come up with a few interesting articles, for
example:

http://groups.google.com/groups?selm=37B01650.F7DA4BD6%40zko.dec.com

(in which David Butenhof says "Another thing to remember: even when
you CAN achieve fairness, you should avoid
it.")

>You may also want to take a look at what The Inventor [well, sort-of]
>of the "mutual exclusion" wrote about it [in the 1960s or early 1970s,
>IIRC] -- see <http://www.amazon.com/exec/obidos/ASIN/0387954015>...

Hopefully, you'll be able to point me to exactly the part in the book
you had in mind, unless you want to wait 2 months (approx ship time
from Amazon to Israel) for my reply...

Ziv

Alexander Terekhov

unread,
Dec 9, 2002, 5:36:11 AM12/9/02
to

Ziv Caspi wrote:
>
> On Fri, 06 Dec 2002 11:43:13 +0100, Alexander Terekhov
> <tere...@web.de> wrote:
>
> >Sure. One may construct infinite number of brain-dead things [such as
> >MS-mutant-aka-MS-mutex]. Well, name calling aside, I guess, it's time
> >for you to fire a search on "mutex fairness" [or just ask Pavel ;-)].
>
> Google search gives >2000 results. Surely a better pointer could prove
> useful?
>
> Searching this group did come up with a few interesting articles, for
> example:
>
> http://groups.google.com/groups?selm=37B01650.F7DA4BD6%40zko.dec.com

Nice hit. ;-)

>
> (in which David Butenhof says "Another thing to remember: even when
> you CAN achieve fairness, you should avoid
> it.")
>
> >You may also want to take a look at what The Inventor [well, sort-of]
> >of the "mutual exclusion" wrote about it [in the 1960s or early 1970s,
> >IIRC] -- see <http://www.amazon.com/exec/obidos/ASIN/0387954015>...
>
> Hopefully, you'll be able to point me to exactly the part in the book
> you had in mind, unless you want to wait 2 months (approx ship time
> from Amazon to Israel) for my reply...

http://www.cs.utexas.edu/users/EWD
http://www.cs.utexas.edu/users/EWD/ewd03xx/EWD310.PDF
(Hierarchical ordering of sequential processes, 1971)

"...We inroduce the semaphore ``mutex''... The choice of the
process to be woken up is left undefined because... such a
neutral policy which is adequate for granting entrance into
critical sections will certainly be inadequate for granting
a scarce resource like a printer. For the implementation of
less neutral granting policy we shall use critical sections,
entrance to which is granted on a neutral basis. ...Problem
of Dining Philosophers to be treated later.) ... introducing
besides the state ``hungry'' also the state ``very hungry''
..."

regards,
alexander.

Ziv Caspi

unread,
Dec 13, 2002, 4:50:52 AM12/13/02
to
On Mon, 09 Dec 2002 11:36:11 +0100, Alexander Terekhov
<tere...@web.de> wrote:

:-)

>http://www.cs.utexas.edu/users/EWD
>http://www.cs.utexas.edu/users/EWD/ewd03xx/EWD310.PDF

Thanks for the link.

>(Hierarchical ordering of sequential processes, 1971)
>
>"...We inroduce the semaphore ``mutex''... The choice of the
> process to be woken up is left undefined because... such a
> neutral policy which is adequate for granting entrance into
> critical sections will certainly be inadequate for granting
> a scarce resource like a printer. For the implementation of
> less neutral granting policy we shall use critical sections,
> entrance to which is granted on a neutral basis. ...Problem
> of Dining Philosophers to be treated later.) ... introducing
> besides the state ``hungry'' also the state ``very hungry''
> ..."

You seem to be missing EWD's point here. What he says throughout his
argument is that mutex objects must not be used to enforce policy.
Rather, they should be guardians for pieces of code that make their
own policy. (Thus, the underlying layer provides basic mutual
exclusion mechanisms, and the upper layer -- perhaps a 3rd "secretary"
party -- does policy decisions.) The crux of his argument is that for
such a scheme to work, the mutex must be what EWD calls "fair".

But EWD's "fairness" is not what most people would call "fairness".
His strict definition is that fairness means no client waiting for a
mutex that is continuously being released will do so forever. A mutex
that allows process A in twice as many times as process B is, under
EWS's definition, "fair", as long as B gets to "eventually enter" the
mutex.

Going back to the original issue, I'm sure you'd be glad to learn that
Windows mutex objects are fair, where "fair" is using EWD's
definition. In fact, they rarely deviate from a FIFO pattern (*).

Ziv

(*) Essentially, a thread waiting for a mutex is put at the end of a
FIFO waiting list. However, the thread can be knocked off the list
temporarily due to APCs, in which case when it returns to waiting it
is put at the end of the list -- thus losing its previous position.

Alexander Terekhov

unread,
Dec 13, 2002, 5:27:38 AM12/13/02
to

Ziv Caspi wrote:
[...]

> You seem to be missing EWD's point here. What he says throughout his
> argument is that mutex objects must not be used to enforce policy.
> Rather, they should be guardians for pieces of code that make their
> own policy. (Thus, the underlying layer provides basic mutual
> exclusion mechanisms, and the upper layer -- perhaps a 3rd "secretary"
> party -- does policy decisions.)

Yeah. And, BTW, "secretary" is [pretty much] what later was called
condvar(s)-based-"monitor".

As for the rest of your message/conclusions, well, ``try again.''

regards,
alexander.

P.S. Someone is indeed missing the point here. I agree. ;-)

Ziv Caspi

unread,
Dec 13, 2002, 4:31:32 PM12/13/02
to

You "try again".

This discussion started by you throwing mud at mutexes as they're
implemented by Windows. I believe I've addressed each and every issue
you've raised in this (long) thread. Turning to "you're so wrong I
needn't even bother to explain why" type of arguments doesn't help
your case. It simply demonstrates that you have run out of technical
arguments.

Ziv

Alexander Terekhov

unread,
Dec 14, 2002, 10:41:49 AM12/14/02
to

Ziv Caspi wrote:
[...]

> This discussion started by you throwing mud at mutexes as they're
> implemented by Windows.

Because MS-"mutex"-thing is really "brain dead" creature.

> I believe I've addressed each and every issue you've raised in
> this (long) thread.

Yeah. Sort of.

> Turning to "you're so wrong I needn't even bother to explain why"
> type of arguments doesn't help your case.

You mean class-action? ;-) Seriously, with respect to mutex "fairness"
[MS-"mutex"-FIFO-ness], reread the paper and the article you've managed
to find on google.

regards,
alexander.

Ziv Caspi

unread,
Dec 14, 2002, 4:38:21 PM12/14/02
to
On Sat, 14 Dec 2002 16:41:49 +0100, Alexander Terekhov
<tere...@web.de> wrote:

>> Turning to "you're so wrong I needn't even bother to explain why"
>> type of arguments doesn't help your case.
>
>You mean class-action? ;-) Seriously, with respect to mutex "fairness"
>[MS-"mutex"-FIFO-ness], reread the paper and the article you've managed
>to find on google.

Going nowhere twice....

Ziv

Alexander Terekhov

unread,
Dec 14, 2002, 5:58:02 PM12/14/02
to

Go here [yes, I know that you're already familiar with it ;-) ]:

http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dllproc/base/mutex_objects.asp

"....
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, <snip blah-blah>"

Now go here [for example]:

http://groups.google.com/groups?selm=32DC51CF.5E70%40zko.dec.com
http://groups.google.com/groups?selm=3316D831.41C6%40zko.dec.com

Q) Does this help?

regards,
alexander.

P.S. Ziv, let's now discuss MS-"mutex"-*abandoned* "feature"... ;-)

--
http://www.microsoft.com/msj/defaulttop.asp?page=/msj/archive/s1da0a.htm#fig2
("OPTEX"-beast... it has even *timed* wait/lock "feature" ;-) ;-) )

Ziv Caspi

unread,
Dec 19, 2002, 4:54:41 PM12/19/02
to
On Sat, 14 Dec 2002 23:58:02 +0100, Alexander Terekhov
<tere...@web.de> wrote:

>Q) Does this help?

No, of course it doesn't, but then you already knew that, didn't you?

Ziv

Reply all
Reply to author
Forward
0 new messages