Re: Threads docs updated in CVS

From: williamkempf_at_[hidden]
Date: 2001-08-15 19:44:51

--- In boost_at_y..., John Max Skaller <skaller_at_m...> wrote:
> Ross Smith wrote:
> 
> > It's not the concept I'm objecting to, it's the terminology. I 
expalined
> > my problem with it in an earlier mail: "join" is a meaningless 
term.
> 
> 	But it's only a name: names are not unimportant,
> but Bill's rationale seems reasonable: boost's join is enough like
> POSIX join to use the same term, and it has one huge advantage,
> which is that it is tiny. :-) [only four characters]

More in another post...
 
> > >         So I ask: if you want to use event synchronisation,
> > > what is stopping you? You don't _have_ to join a thread,
> > > nor do you have to detach it. True, you can't _currently_
> > > use events for synchronisation, but could they not
> > > be added as a later extension?
> > >
> > >         What I'm asking is: is there a genuine conflict,
> > > or merely an omission?
> > 
> > I'm still lost.
> 
> 	I can only repeat myself. Does the lack of events
> create a _conflict_, or are they simply missing, so that
> they could be added later.

Simply missing, no conflict.
 
> 	If they can be added later, I am less concerned
> than if they cannot be added later (that is, the current
> design precludes them).

They can be added easily later (after working out the proper design).
 
> > >         So please comment. It is my understanding that
> > > events are
> > >
> > >         a) more general
> > >         b) harder to use
> > >
> > > than more specific synchronisation techniques. Would you agree?
> > 
> > I don't grok CVs well enough to say whether they're more or less 
general
> > than events, but I certainly disagree with the second part. CVs 
are a
> > complicated linkage of several disparate concepts -- mutex, 
predicate,
> > etc -- that require careful analysis to figure out how to use them
> > properly in any particular situation. Events are very simple: one 
thread
> > sets an event, another waits for it. What could be simpler?
> 
> 	What happens if two threads wait for an event?

That depends on the type of event ;).  Seriously, in Win32 there are 
two event types, auto reset events and manual reset events.  With a 
manual reset event any threads waiting on the event when it's 
signaled are released and any threads that attempt to wait on the 
event before it's reset are also released immediately.  With an auto 
reset event only one thread is released and then the event is 
automatically reset.

> Can you set an event again?

Not until it's been reset (manually or automatically).

> if so, how do you know that the
> waiting thread has stopped waiting (on the first event)?

Not really a valid question for either type.

> Or do I misunderstand: does the thread setting the event
> wait until the other thread has noticed? Events might
> be simple, but your simplified explanation of them 
> isn't enough for me to understand the semantics.
> Can you try to explain the semantics precisely?

I've given a better explanation, but this is Win32 specific.  Even if 
Boost.Threads includes events in the future there's no guarantee that 
they will work in precisely the same manner.
 
Bill Kempf