Subj : Re: Thoughts about threads in C++
To   : comp.programming.threads
From : Maciej Sobczak
Date : Sun May 01 2005 12:12 am

Hi,

Jomu wrote:

>   It is maybe because of me "not talking C++" here that I am not
> understood well.

OK. Well, I'm sorry to say that, but it would be much better to have 
some expertise in C++ before discussing the validity (or lack thereof) 
of its extension w.r.t. multithreading.

Anyway, here's the short story:

The RAII idiom is the most basic and fundamental idiom in C++ - it is 
essential for exception safety. It is everywhere and what's more, it is 
already "there" in the sense that it is recognizable and it just "writes 
itself" when you use this language actively. This means that applying 
this idiom to locking a mutex (or acquiring any resource in general) is 
not an "add-on", but simply the consistent usage of the language.

int i;   // variable that is shared between threads
mutex m; // used to guard the access to variable i

void fun()
{
     lock l(m);   // mutex is locked
     i = 7;
}                // mutex is implicitly unlocked

Above, l is a local object that will be destroyed when it goes out of 
scope - you know that the destruction of l will take place no matter how 
the scope is left. This is where the implicit unlock is buried.

This is how *all* resources are managed in a well-written C++.
Lock "regions" would be foreigners in this world.

> You plan to use one add-on to do locking, and create
> another to define concurrency. In my book, this mixup is not good
> design technique.

I see your point. However, there is no mix.

First of all, usage of RAII idiom for locking a mutex is not an add-on - 
this is a well-established idiom that is already present in the 
language. Locking a mutex is just acquiring a resource and as such is 
nothing that would be conceptually new. Locking falls into the broad 
category of resource acquisition.
So we are done with locking. :)

What's missing is the way to say "I want this-and-that to run 
concurrently". There is nothing in the language that allows me to say 
it. My position is that this should not be done by library-based sugar, 
because there will always be some paradigma present where it doesn't 
really belong. In my humble opinion, we have to acknowledge that 
concurrency is something new in the language and we can do this by 
providing dedicated control statements to say things as they are.
But then - if we decide to add something that we acknowledge is new 
(remember that locking isn't), then there is nothing with which it could 
possibly mix.

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

.