Subj : Re: Thoughts about threads in C++
To   : comp.programming.threads
From : Maciej Sobczak
Date : Fri Apr 29 2005 06:27 pm

Hi,

Jomu wrote:

>   Do not fail in preserving fragile programmer's minds!

That's not about preserving programmers, but rather about adapting the 
language to so that I can say things as they are.

MT programming cannot be simpler by just adding syntactic sugar.
But when the code becomes more descriptive, I'd go for it.

>   Java tried to preserve poor programmers. They ended with "every
> object is mutex and also condvar". Learn from them.

Did I wrote anything like this?

>   You have cobegin/coend (Dijkstra, sixties) there. What you lack is
> "region" and "shared" or "LOCK" to get suite at least running.

No. I do not want the "lock" regions and friends. I want explicit 
objects on which threads can synchronize by calling their methods. Mutex 
and convar are obvious in this approach.

>>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
> 
>   Done implicitly in most systems.
> 
> 
>>c. run everything explicitly in separate pipelines of the multicore
> 
> CPU,
> 
>>which actually does not require any OS-level threading at all
> 
> 
>   It always needs some "OS-level", at least to manage OS resource
> sharing.

Unless you are in the freestanding environment, where your program is 
actually the only software that is running?

>> (see questions at the
>> end of the referenced article).

>   I've read them. How do you plan to timeout or generally abort some
> stuck thread?

I don't.
You probably have to see the question and responses again. :)


>   I am not talking C++, I am talking threads and syntactic sugar :).

I'm talking C++. See the title of my original (and this) post.


> And when two (or three,
> with rwlock) basic elements are objects, why run from "thread is
> object"?

Because from all these, threads aren't objects.

For me, thread is a fact of executing something. I don't want any object 
for this. Similarly, I do not want any object for the two branches of 
the "if" statement, I do not want any object for the cases in the 
"switch" statement, etc.
In general, I don't need any object to say that something gets executed.


>   But why don't pass them as reference also?

You cannot pass everything by reference without the need to explicitly 
synchronize the moments when it is safe for any thread to continue with 
their data (not everything has to be shared). It is convenient to have 
at least one thing passed by value to avoid this explicit 
synchronization calls.
In pthreads you also pass the parameter by value (the void* pointer is 
passed by value).
In what I propose, every object in the outer scope that has an 
*automatic* storage duration (this is important - think about it) and 
that is also referenced in the async threaded block gets copied.

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

.