This is the mail archive of the
mailing list for the Cygwin project.
pshared mutex's and cond variables - does anyone use them?
- To: Frederic Devernay <Frederic dot Devernay at sophia dot inria dot fr>
- Subject: pshared mutex's and cond variables - does anyone use them?
- From: Robert Collins <robert dot collins at itdomain dot com dot au>
- Date: 30 Aug 2001 19:40:19 +1000
- Cc: cygwin at cygwin dot com, Olivier Bantiche <Olivier dot Bantiche at sophia dot inria dot fr>
- References: <20010830094600.A9594@perf.inria.fr>
On 30 Aug 2001 09:46:00 +0200, Frederic Devernay wrote:
> there are officially two ways to initialize a pthread mutex:
> pthread_mutex_t mut = PTHREAD_MUTEX_INITIALIZER;
> pthread_mutex_t mut;
> the problem is that the pthread_mutex_init in cygwin reads the of-course
> uninitialized memory:
> as seen in cygwin-1.3.2-1/winsup/cygwin/thread.cc:
> __pthread_mutex_init (pthread_mutex_t * mutex,
> const pthread_mutexattr_t * attr)
> if ((((pshared_mutex *)(mutex))->flags & SYS_BASE == SYS_BASE))
> // a pshared mutex
> return EBUSY;
> If found this bug not by declaring a local variable as above, but by allocating
> the mutex. the only workaround I found was to memset the memory area before
> calling pthread_mutex_init.
> I don't know what a pshared_mutex is, but pthread_mutex_init should really
> not assume that anything is valid in the given mutex!
Yes, this is a known bug, last discussed right here about a week ago!.
I'm seriously considering pulling the pshared code out of pthreads
They cannot be implemented cleanly pending some significant work within
cygwin1.dll, which has no timeframe (by this I mean a daemon for
They add significantly to the internal complexity in the meantime...
Also note, that it is always possible to confuse pthread_mutex_init, on
most platforms, but it shouldn't be possible to cause a segfault or
anything nasty like that :].
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Bug reporting: http://cygwin.com/bugs.html