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

From: Hurd, Matthew (hurdm_at_[hidden])
Date: 2004-01-26 21:31:24

> On Behalf Of Sean Kelly
> Subject: RE: [boost] Boost.Thread request: event object
> 
> 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.

So are you saying that multiple threads calling WaitForSingleObject for
the same event is not safe or is the lack of safety elsewhere in the
windows event mechanism.  I wouldn't mind a source url or something for
this if you have one so I can come up to speed.

> > 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).

I think WSFU if a crimson herring, best to forget about it.

> > 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.

Hmmm, not sure... might never get out of the bike shed with this one ;-)

Doesn't seem to be a common name in the literature that I can discern.

Name should work with mutex, timer, socket i/o and file i/o.  Lock
doesn't.  
Accepting signals, events or notifications.  

Nothing I can think of quite has the same ring to it as "lock" does for
mutex, but lock is misleading for events and signals.  Must support the
idea of shareable possession as well for the common case of read write
locks.

Maybe a verb like "acquire" makes sense as it should really actioned at
construction time and then let dissolve as it rolls out of scope.

socket_event e( some_socket_thing );

if (acquire ev(e,t)) {

}
                
mutex guard;
if (acquire lock(guard	,t)) {

}

looks cute.  Perhaps "wait".

> > 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.

Strikes me that a WFMO is pretty fundamental here and a bit more
prospecting would be good.  

A good case study with timers, mutexes and aysnch i/o would be the next
step I think.

Regards,

Matt Hurd.

IMPORTANT: The information contained in this email and/or its attachments is confidential. If you are not the intended recipient, please notify the sender immediately by reply and immediately delete this message and all its attachments.  Any review, use, reproduction, disclosure or dissemination of this message or any attachment by an unintended recipient is strictly prohibited.  Neither this message nor any attachment is intended as or should be construed as an offer, solicitation or recommendation to buy or sell any security or other financial instrument.  Neither the sender, his or her employer nor any of their respective affiliates makes any warranties as to the completeness or accuracy of any of the information contained herein or that this message or any of its attachments is free of viruses.