Subj : Re: Thoughts about threads in C++
To   : comp.programming.threads
From : Jomu
Date : Fri Apr 29 2005 12:56 pm

Maciej Sobczak wrote:
....
>
> >   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?

  This unfinished part of proposal will tell, once you finish it :).

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

  They are not, and for one very simple reason - with "lock" and
friends you have implicit finalization of "lock" section. Programmers
do not have to count their locks and match them with their unlocks if
you add this in your syntax. This is more important than do you or do
you not know/have/use thread id or how do you "join" your threads.

  With your threading syntax and short of "lock" syntax, your design is
half here and half there.

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

  Right. But I can't see C++ there, really.
....

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

  You are talking threads. See newsgroup name.

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

  No wonder pl.* discussions were heated, then :).

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

  Your "threaded" code is not cut off in some way. It's fork()
semantic, where stack is copied to every of your threads, async or not,
and for these threads, automatic storage remains where it is (copied by
value, just like in fork()). Maybe that is better explanation than one
given in proposal?

  You don't need POSIX for this on most platforms :). Linux clone()
will skip "overhead" for you.

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


  dd

.