db8
Subj : Re: Thoughts about threads in C++
To   : comp.programming.threads
From : Maciej Sobczak
Date : Thu Apr 28 2005 06:18 pm

Hi,

Jomu wrote:
> It seems you would like to trade "function" and "object" approachs for
> "syntactic sugar" approach.

No. I'd like to trade one syntactic sugar for another. :)

> Nothing bad in that, except you'll need
> some kind of "handle" for your threads

This is what I want to avoid - intentionally.
I'm not interested in handles - these expose implementation details, 
even when they are wrapped into "objects". What I'm interested in is 
that I want to do something in paraller to something else. Only that.
Consider:

threaded
{
     // instructions 1.
}
other
{
     // instructions 2.
}

What I want to say by this is that instructions 1. and 2. should be 
executed in paraller. That's all. I don't care whether there will be a 
new physical thread created to do this. The implementation has to do 
what it has to do, whether this is:
a. creating a new physical thread and releasing it afterwards
b. reusing a thread that was created previously
c. run everything explicitly in separate pipelines of the multicore CPU, 
which actually does not require any OS-level threading at all
d. (whatever else)

By explicitly creating threads and messing with their IDs (or handles) I 
bind myself to a. or b., which at this level is irrelevant to me.
What is relevant is the concurrency. I'd like the implementation and the 
environment to pick the low-level scheme for me.

 > so you can cancel them, suspend
> them, whatever them by some id.

Which is what I do not want to do on this level (see questions at the 
end of the referenced article).

When I actually do want to do something that is outside of this scheme 
(and it may happen from time to time), I can do it with "traditional" 
approaches, which will usually boil down to APIs like pthreads.
Please note that if Boost.Threads gets into the C++ standard, it will be 
in the same position - most of the time it will be enough for general 
use but when it is not (have you seen cancel, suspend, whatever there?), 
people will call low-level APIs directly. This is to be expected. If 
that has to be the case, I see no purpose for IDs or objects.


> Also, your scope rules seem clumsy at one fast reading so
> it's maybe best to keep "thread body is function/method body" and rely
> on established/accepted/understood scope rules.

This is a valid point, which I understand. On the other hand, by 
introducing concurrency into the language you may expect to stirr things 
a little bit, especially in the context of lifetime rules.
What I described is essentially no different from the 
established/accepted/understood approaches when you pass things by value 
to the new thread, even if it then becomes a dangling pointer. ;)

> Important thing to note, IMHO, is: pthreads approach is also "threads
> are objects". They are definitely object based, even in their simplest
> "C library" form.

Of course. If you extrapolate this by saying that any object-based 
wrapper around pthreads gives nothing but syntactic sugar, I will agree. 
That's why I think that the existence of concurrency in the program has 
to be acknowledged at the level of control statements, and not hidden 
behind objects, functions (or even functors) and IDs.

-- 
Maciej Sobczak : http://www.msobczak.com/
Programming    : http://www.msobczak.com/prog/

.

0