Subj : Re: Thoughts about threads in C++
To   : comp.programming.threads
From : Maciej Sobczak
Date : Sat Apr 30 2005 01:18 am

Hi,

Jomu wrote:

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

I thought that I wrote about *RAII* handlers for the synchronization 
objects, like Boost's mutex::lock.

<checking again if it is mentioned there>

It is there. You certainly skipped the "Library support" part.


>>In general, I don't need any object to say that something gets
> 
> executed.
> 
>   No wonder pl.* discussions were heated, then :).

Yes, it proved to be a shock to a lot of people. :)

Small excercise:

if (condition)
{
     // instructions A
}
else
{
     // instructions B
}

Just for the warm-up, remove this control statement from the language 
and provide something that will do the same, but that will require (or 
introduce) an object for each branch of this statement. In addition, 
force people to use pointers to functions (or functors) for each branch 
instead of regular blocks of statements.
"Not a good idea"?

Now:

threaded
{
     // instructions A
}
other
{
     // instructions B
}

And you hear: "nonsense". Go figure. ;)


>   Your "threaded" code is not cut off in some way. It's fork()
> semantic, where stack is copied to every of your threads,  [...]

I'm surprised that you came to this conclusion.
The stack is not copied (whatever that might mean). The straightforward 
implementation with pthreads (just for example) is to create a structure 
that contains the copies of local objects that have automatic storage 
duration (and only those that are accessed in the concurrent block) and 
push this structure (or the pointer to it) to the starting function of 
the new thread. This is what you'd do today by hand.


>   You don't need POSIX for this on most platforms :).

I know, but implementability in terms of POSIX means that it is nothing 
really esotheric.

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

.