public inbox for pthreads-win32@sourceware.org
 help / color / mirror / Atom feed
* mutex_lock on solaris vs. winnt
@ 2000-07-27  9:37 Hung Huynh
  0 siblings, 0 replies; 3+ messages in thread
From: Hung Huynh @ 2000-07-27  9:37 UTC (permalink / raw)
  To: pthreads-win32

Hi!

I'm trying to port some code from unix (solaris) to windows nt.
The code uses pthread mutexes to create a binary semaphore for
reading (many-at-a-time) and writing (one-at-a-time).

I have just found out that if you in unix do pthread_unix_lock
twice on the same mutex, and in the same process, you will lock. But
trying to do the same thing in windows nt (with pthread-win32 released
1999-11-02)
won't give the same behaviour. Is this because the WaitForSingleObject
in windows
will allow multiple locks in the same process? Should it be like this or
is it
something that is just not yet implemented in pthread-win32?

As you can tell I'm a newbie, and i'll appreciate very much any
information
on this. Thank you in advance.

/Hung

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

* Re: mutex_lock on solaris vs. winnt
  2000-07-27  9:47 Bossom, John
@ 2000-07-27 16:53 ` Ross Johnson
  0 siblings, 0 replies; 3+ messages in thread
From: Ross Johnson @ 2000-07-27 16:53 UTC (permalink / raw)
  To: Bossom, John; +Cc: 'Hung Huynh', pthreads-win32

Since Hung's message describes it as the behaviour being sought,
I would just add that both Solaris and Pthreads-win32 have
read-write locks.

      ---------------------------
      Read/Write Locks:
      ---------------------------
      pthread_rwlock_init
      pthread_rwlock_destroy
      pthread_rwlock_tryrdlock
      pthread_rwlock_trywrlock
      pthread_rwlock_rdlock
      pthread_rwlock_rwlock
      pthread_rwlock_unlock                                             

Ross

"Bossom, John" wrote:
> 
> pthread_mutex is implemented on Win32 using Win32 primitive
> locking mechanisms. These primitives are inherently recursive
> in nature (i.e. the same thread may re-acquire the lock multiple
> times... internally they keep a count of the # of times it has
> been called)
> Microsoft decided to do this to prevent a thread from deadlocking
> itself. There are non-standard versions of PThreads on various
> UNIX platforms that allow you to declare a mutex as recursive.
> However, it is recommended that if you want PORTABLE code, that
> you do not rely on recursive mutex support... Since you have this
> code on UNIX and had attempted to acquire a mutex lock twice in the
> same thread, you've basically deadlocked your thread permanently...
> I would recommend you re-organize your code such that you do not
> re-acquire the same mutex...
> 
> Cheers,
> 
> John.
> 
> -----Original Message-----
> From: Hung Huynh [ mailto:Hung.Huynh@emw.ericsson.se ]
> Sent: Thursday, July 27, 2000 12:37 PM
> To: pthreads-win32@sourceware.cygnus.com
> Subject: mutex_lock on solaris vs. winnt
> 
> Hi!
> 
> I'm trying to port some code from unix (solaris) to windows nt.
> The code uses pthread mutexes to create a binary semaphore for
> reading (many-at-a-time) and writing (one-at-a-time).
> 
> I have just found out that if you in unix do pthread_unix_lock
> twice on the same mutex, and in the same process, you will lock. But
> trying to do the same thing in windows nt (with pthread-win32 released
> 1999-11-02)
> won't give the same behaviour. Is this because the WaitForSingleObject
> in windows
> will allow multiple locks in the same process? Should it be like this or
> is it
> something that is just not yet implemented in pthread-win32?
> 
> As you can tell I'm a newbie, and i'll appreciate very much any
> information
> on this. Thank you in advance.
> 
> /Hung

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

* RE: mutex_lock on solaris vs. winnt
@ 2000-07-27  9:47 Bossom, John
  2000-07-27 16:53 ` Ross Johnson
  0 siblings, 1 reply; 3+ messages in thread
From: Bossom, John @ 2000-07-27  9:47 UTC (permalink / raw)
  To: 'Hung Huynh', pthreads-win32

pthread_mutex is implemented on Win32 using Win32 primitive
locking mechanisms. These primitives are inherently recursive
in nature (i.e. the same thread may re-acquire the lock multiple
times... internally they keep a count of the # of times it has
been called)
Microsoft decided to do this to prevent a thread from deadlocking
itself. There are non-standard versions of PThreads on various
UNIX platforms that allow you to declare a mutex as recursive.
However, it is recommended that if you want PORTABLE code, that
you do not rely on recursive mutex support... Since you have this
code on UNIX and had attempted to acquire a mutex lock twice in the
same thread, you've basically deadlocked your thread permanently...
I would recommend you re-organize your code such that you do not
re-acquire the same mutex...

Cheers,

John.

-----Original Message-----
From: Hung Huynh [ mailto:Hung.Huynh@emw.ericsson.se ]
Sent: Thursday, July 27, 2000 12:37 PM
To: pthreads-win32@sourceware.cygnus.com
Subject: mutex_lock on solaris vs. winnt


Hi!

I'm trying to port some code from unix (solaris) to windows nt.
The code uses pthread mutexes to create a binary semaphore for
reading (many-at-a-time) and writing (one-at-a-time).

I have just found out that if you in unix do pthread_unix_lock
twice on the same mutex, and in the same process, you will lock. But
trying to do the same thing in windows nt (with pthread-win32 released
1999-11-02)
won't give the same behaviour. Is this because the WaitForSingleObject
in windows
will allow multiple locks in the same process? Should it be like this or
is it
something that is just not yet implemented in pthread-win32?

As you can tell I'm a newbie, and i'll appreciate very much any
information
on this. Thank you in advance.

/Hung

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

end of thread, other threads:[~2000-07-27 16:53 UTC | newest]

Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2000-07-27  9:37 mutex_lock on solaris vs. winnt Hung Huynh
2000-07-27  9:47 Bossom, John
2000-07-27 16:53 ` 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).