Re: [Boost-users] Re: Semaphore and barriers for boost-threads?

On Mon, Feb 16, 2004 at 08:33:47PM -0500, Michael Glassford wrote:

The original designer of the Boost.Thread library and others felt that semaphores were too easily misused, leading to errors (see http://boost.org/libs/thread/doc/rationale.html#events). Others have argued the issue on the various Boost mailing lists at some length more than once; some have been convinced that the "too easily misused" argument has merit, others have not.

OK, well I don't do much Windows programming, so I don't really understand what event variables are. I'll have to do my homework and read up on them. In terms of explaining what a semaphore is, my frame of reference is the stuff in POSIX: http://www.opengroup.org/onlinepubs/007904975/functions/sem_post.html http://www.opengroup.org/onlinepubs/007904975/functions/sem_wait.html http://www.opengroup.org/onlinepubs/007904975/functions/sem_trywait.html http://www.opengroup.org/onlinepubs/007904975/functions/sem_timedwait.html Basically, a semaphore is initialized with a count. When you call sem_post(), the semaphore count is incremented. When you call sem_wait(), if the semaphore count is 0, then the thread blocks, else the semaphore count is decremented. It is possible to implement semaphore's with mutexes and condition variables. I looked at the source code for FreeBSD 5.2's implementation of semaphores to see how this was done: http://www.freebsd.org/cgi/cvsweb.cgi/~checkout~/src/lib/libpthread/thread/t... I even took a whack at writing one based on Boost (it may be buggy): #include #include struct mysem { mysem(unsigned int count): count_(count) {} void post() { boost::mutex::scoped_lock l(sem_mutex_); ++count_; sem_cond_.notify_all(); } void wait() { boost::mutex::scoped_lock l(sem_mutex_); for(;;) { if( count_ == 0 ) sem_cond_.wait(l); else { --count_; break; } } } private: unsigned int count_; boost::mutex sem_mutex_; boost::condition sem_cond_; }; What kinds of things can go wrong if I use this class?

As far as adding a barrier class, however: one has existed in the thread_dev branch in CVS for quite some time; I hope to move it to the main branch very soon.

Cool, thanks! -- Craig Rodrigues http://crodrigues.org rodrigc@crodrigues.org