public inbox for pthreads-win32@sourceware.org
 help / color / mirror / Atom feed
* RE: mutexes
@ 2000-07-24  8:03 Bossom, John
  0 siblings, 0 replies; 3+ messages in thread
From: Bossom, John @ 2000-07-24  8:03 UTC (permalink / raw)
  To: 'uGAH man', pthread

Win32 mutexes are recursive by default!

i.e. the thread that owns the lock can re-acquire the lock...
     you have to have as many unlocks as locks....


-----Original Message-----
From: uGAH man [ mailto:snake@drinkordie.com ]
Sent: Friday, July 21, 2000 3:18 PM
To: pthread
Subject: mutexes


i was testing this pthread for win32 in my prog.
when i checked if it was blocking mutex_lock calls, i was surprised when it
didnt lock

pthread_mutex_t DBlock;

pthread_mutex_init( &DBlock, NULL );
pthread_mutex_lock( &DBlock );
pthread_mutex_lock( &DBlock );

^^ these two calls didnt block

im wondering, why ?
could anyone help ?

^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: mutexes
  2000-07-21 12:19 mutexes uGAH man
@ 2000-07-21 22:24 ` Ross Johnson
  0 siblings, 0 replies; 3+ messages in thread
From: Ross Johnson @ 2000-07-21 22:24 UTC (permalink / raw)
  To: uGAH man; +Cc: pthread

uGAH man wrote:
> 
> i was testing this pthread for win32 in my prog.
> when i checked if it was blocking mutex_lock calls, i was surprised when it
> didnt lock
> 
> pthread_mutex_t DBlock;
> 
> pthread_mutex_init( &DBlock, NULL );
> pthread_mutex_lock( &DBlock );
> pthread_mutex_lock( &DBlock );
> 
> ^^ these two calls didnt block

This appears to be a FAQ.

POSIX leaves the result "undefined" for a thread that tries
to recursively lock the same mutex (one that it owns already).
That means the actual semantics are left up to the
implementation, but should not be relied upon for code that
will be ported to different POSIX threads implementations.

In the pthreads-win32 implementation a thread won't deadlock
itself by relocking the mutex. Subsequent calls to
pthread_mutex_lock() as in your example above increment
the lock count but the thread continues on. Consequently,
the thread must ensure that it unlocks the mutex once for
each lock operation. That is, pthreads-win32 mutexes are
always recursive.

You may want to look at the other synchronisation devices
available in the library, such as condition variables or
read-write locks.

Ross

^ permalink raw reply	[flat|nested] 3+ messages in thread

* mutexes
@ 2000-07-21 12:19 uGAH man
  2000-07-21 22:24 ` mutexes Ross Johnson
  0 siblings, 1 reply; 3+ messages in thread
From: uGAH man @ 2000-07-21 12:19 UTC (permalink / raw)
  To: pthread

i was testing this pthread for win32 in my prog.
when i checked if it was blocking mutex_lock calls, i was surprised when it
didnt lock

pthread_mutex_t DBlock;

pthread_mutex_init( &DBlock, NULL );
pthread_mutex_lock( &DBlock );
pthread_mutex_lock( &DBlock );

^^ these two calls didnt block

im wondering, why ?
could anyone help ?

^ permalink raw reply	[flat|nested] 3+ messages in thread

end of thread, other threads:[~2000-07-24  8:03 UTC | newest]

Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2000-07-24  8:03 mutexes Bossom, John
  -- strict thread matches above, loose matches on Subject: below --
2000-07-21 12:19 mutexes uGAH man
2000-07-21 22:24 ` mutexes Ross Johnson

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).