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

From: Ross Smith (ross.s_at_[hidden])
Date: 2001-08-10 23:41:59

John Max Skaller wrote:
> 
> 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'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. It
may be the common term for this concept in the literature (altough I'd
take a lot of convincing that this wasn't simply a result of general
familiarity with pthreads), but that doesn't make it a good idea. ("If
everybody else jumped off a bridge...") And I notice that since then, at
least one other person has agreed with me.

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

Errr ... I'm sorry, I honestly can't understand what you were trying to
say in that paragraph.

>         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. You seem to be seeing some connection between the
"should detach be allowed?" question and the "do we use CVs or events?"
question. I don't know what connection you see, they seem orthogonal to
me. If that's not what you meant, then ... er ... what _did_ you mean?

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

Exactly. That was the point I was trying to make, and I agree with
everything you said about it.

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

I'll admit I mas out of line with my brainwashing remark. I'm probably
over sensitive on that particular point because of the regular arguments
I have with my boss on this particular subject, and in his case I know
him well enough to be quite sure it _is_ a "Unix does it this way so
that proves it's the right way" attitude.

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

I'm willing to be educated on this point, but only by actual rational
argument. Bare assertions that events are more likely to lead to race
conditions aren't good enough (and neither is "because Knuth says so").
If someone can present a solid argument that justifies that claim, I'll
apologise and withdraw my objection. But not until I see it.

(Last time this came up someone pointed to an error in my own
event-based code, and claimed that the fact that my CV-based version of
the same code didn't have the error was evidence that events were bad.
Sorry, I'm not arrogant enough for that line of argument to work; a bug
in my code proves nothing more profound than the fact that I can make a
mistake.)

-- 
Ross Smith <ross.s_at_[hidden]> The Internet Group, Auckland, New Zealand
========================================================================
"Unix has always lurked provocatively in the background of the operating
system wars, like the Russian Army."                  -- Neal Stephenson