$include_dir="/home/hyper-archives/boost/include"; include("$include_dir/msg-header.inc") ?>
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