Re: [boost] Re: Threads docs updated in CVS

From: John Max Skaller (skaller_at_[hidden])
Date: 2001-08-14 14:38:30

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]

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

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

> You seem to be seeing some connection between the
> "should detach be allowed?" question and the "do we use CVs or events?"

        Certainly. The connection is: 'what category is each
of your objections in?'

        An abstraction has 'axioms'. It can be incomplete,
in that some desired theorem cannot be derived from
the axioms. It can be inconsistent, in that a contradiction
can be derived from the axioms. It can be verbose, in that
some of the axioms can be derived from others. Each of these
categories of objections are formally distinct.

        Inconsistency is utterly intolerable.
Incompleteness is inevitable (except for simple systems).
Verbosity is usual for computer interfaces, but not too much.

> I'll admit I mas out of line with my brainwashing remark. 

        Only in some circles where politeness is prefered
to quality. :-) We're humans, we work hard at this stuff,
and we need to accept we're emotional beings. People fight
wars: all we're doing is penning words.
 
> >         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?
Can you set an event again? if so, how do you know that the
waiting thread has stopped waiting (on the first event)?
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'm willing to be educated on this point, but only by actual rational
> argument. 

        Be careful here. Rationality will help you determine
the correctness of an argument. But an argument is a way
of deriving a conclusion from axioms. 'Ease of use' isn't
a property which can so easily be derived, since it involves
psychology. When people claimed 'goto considered harmful'
it wasn't a matter of proof that it is hard to reason
about code with goto's scattered about, but a matter
of experience.

        In _my_ experience, the way to go for concurrency
is to use the join calculus: it is the simplest system,
it has superb safety properties compared with anything else,
it is easy to reason about. But my experience is limited,
it may be harder to use in C++, and people aren't familiar 
with it.

-- 
John (Max) Skaller, mailto:skaller_at_[hidden] 
10/1 Toxteth Rd Glebe NSW 2037 Australia voice: 61-2-9660-0850
New generation programming language Felix  http://felix.sourceforge.net
Literate Programming tool Interscript     
http://Interscript.sourceforge.net