|
Boost : |
From: Kevin Atkinson (kevin_at_[hidden])
Date: 2003-02-19 11:11:24
On Wed, 19 Feb 2003, Alexander Terekhov wrote:
> That means that I've figured out whom do you mean...
>
> "Original-To: Gennadiy Rozental <gennadiy.rozental_at_[hidden]>"
>
> ...from the "Original-To"-in-the-headers-to-your-posting-here.
Oh sorry. I really hate forced reply-to. The message was directed at
Gennadiy Rozental but I CCed it to the boost mailing list.
> Kevin Atkinson wrote:
> >
> > > your Mutex class offers undefined behavior;
> > > you really can NOT "replicate" a {pthread_mutex_t} mutex.
> >
> > Where do I replicate a mutex?
>
> "....
> static const pthread_mutex_t MUTEX_INIT = PTHREAD_MUTEX_INITIALIZER;
>
> class Mutex {
> pthread_mutex_t l_;
> public:
> Mutex() : l_(MUTEX_INIT) {}"
> ^^^^^^^^^^^^^^
I believe this behavior is well defined. PTHREAD_MUTEX_INITIALIZE is a
const initializer. Unfortunately for Linux threads it is defined as a
traditional C struct initializer, "{ ... }". So
l_(PTHREAD_MUTEX_INITIALIZER) will not work. Thus I simply make a copy of
it in MUTEX_INIT and use that constant to initialize l_. If it is not
specifically allowed in the POSIX standard it should be. I can not think
of a situation where this will cause a problem. If i was assigning
MUTEX_INIT to an active mutex then yes that would be bad, but I am not
here as I am simply initializing it.
If it bothers you I can use a less efficient initializer:
Mutex() {pthread_mutex_init(&l_, 0);}
But this may involve a function call.
---
http://kevin.atkinson.dhs.org
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk