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

From: John Max Skaller (skaller_at_[hidden])
Date: 2001-08-10 21:20:20

Ross Smith wrote:

> We've been through this and got nowhere. My main objections -- and I'm
> stating these here again just for the record, not because I want to open
> the argument again -- are that it uses too much pthread-specific
> terminology (e.g. "join"), 

        Oh, come one: joining threads isn't pthread specific.
It's a general concept, the terminology is used in a lot
of theoretical literature too.

> it uses condition variables instead of events, 

        That's a more valid concern. Neither of these
ideas is either pthreads or windows specific. But supplying
one synchonisation model rather than another is a genuine
concern.

> it allows threads to be abandoned (detached), 

        If a thread is detached, it can't be joined.
You are correct that detaching a thread, in a way
that _prevents_ joining, is a specific feature.

        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?

> and it allows cancellation. 

        No, the existing model does not permit cancellation.

> Oh, and (although I didn't bring this up before; if it was
> discussed earlier I missed it) I've never been able to see the point of
> thread specific storage.

        I'm not sure what you mean exactly.
There is a reason to have some data which exists for each thread.
In particular, thread specific data structures which are not
shared between threads do not need to be made thread safe.

        But I think you may be asking 'why do we need any
library functions for providing thread specific data?'
and I think that is an excellent question. I don't see any
need for such functions either: the thread can just
create thread specific data the usual way, and pass it
the usual way.

        In my opinion, thread specific data functions
are in Posix because of the faulty Unix/C model.
They exist because programmers are ignorant of good design,
and don't understand that implicitly coupled global data --
including thread specific data -- is bad design.
In particular, if you're trying to upgrade such bad designs
to support threads, then the Posix functions are there
to minimise the effort required.

> I've given up on the whole CV-vs-event mess; to be perfectly honest,
> I've come to the conclusion that most people have been brainwashed by
> the "Unix is always right and Windows is always wrong" school of
> thought, and aren't prepared to discuss the matter rationally.

        Please don't. Its very important that dissenters remain
active here, because if we do not sort through these issues,
there is a good chance the C++ committee will end up rejecting
the library because some people who agree with you won't vote for it.
On the committee, consenus is required. This is not like boost,
it isn't majority rule: EVERONE must agree (more or less).
[Pragmatically, a single objector may be overruled, but if two
National Bodies object, a proposal is usually withdrawn until
agreement can be reached]

        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?
And, more for Bill: is there anything preventing an
event synchronisation subsystem being added to the library?

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