RE: [boost] Boost.Thread request: event object

From: Sean Kelly (sean_at_[hidden])
Date: 2004-01-26 18:30:48

On Mon, 26 Jan 2004, Hurd, Matthew wrote:
>
> Not sure I understand where we are with events:
>
> Can we wrap the acceptance of events from the OS, win32 in particular,
> into a scoped acquisition without introducing race or performance
> problems?

>From the bit of research I did this morning, it appears the problem is
that multiple threads waiting on an event necessarily creates a race
condition, because there is no synchronization mechanism like there is
with pthread conditions.  The condition mechanism in Boost was an attempt
to replicate pthread condition variables in Windows, and used semaphores
and such out of necessity.  While this does leave out simple cases with
Windows events that actually work correctly (such as my example, AFAIK), I
can understand the motivation not to provide a mechanism that is very
likely to be misused.

> I'm not suggesting an event mechanism just being able to use the OS
> efficiently.

I think I'm going to continue to use my own event object for the simple
cases and adopt the Boost method for the complex ones.  Though the more
efficient approach would probably to use real pthreads which are a part of
WSFU (windows services for unix).

> Lock seems a bad name.  Any good short names for an "acquirer" that
> would make sense for a socket, file i/o, timer, mutex?

Resource perhaps?  Except that mutexes manage access to resources and
aren't exactly resources themselves.

> Under the covers on win32 the "acquirer" for the resource just uses
> WaitForSingleObject.
>
> Does this work for you?

For the simple case, yes.  I think I'm going to do a bit more digging
before I commit to more than that, however.

Sean