dc5
Subj : Re: Thoughts about threads in C++
To   : comp.programming.threads
From : Maciej Sobczak
Date : Sun May 01 2005 07:20 pm

Hi,

Jomu wrote:

>>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
> 
> 
>   This is so improvisation and too-much-information and
> what-is-this-for that it hurts my eyes - really.

So welcome to C++. :)

VAR i : INTEGER;
VAR m : MUTEX;

PROCEDURE p;
BEGIN
     LOCK m DO
         i := 7;
     END;
END;

This is so [...] that it hurst my eyes - really. ;)

But let's not flame about different languages. My point is to have 
something that is already known and recognizable to the C++ community. 
RAII certainly is.

> Explicitly naming
> locking scope (ops, that's even an object there) is ok,

You seem to apply the vocabulary from one language to the stuff written 
in another. This leads nowhere. I don't think about it as naming a 
locking scope, but as having a locker. I may lock mutex myself, like here:

m.lock();
i = 7;
m.unlock();

but this is a Bad Thing (it is even forbidden in libraries like 
Boost.Threads). I feel safer having a locker (a "guardian"):

{
     lock l(m);
     i = 7;
}

This is really idiomatic. Call it broken, but this issue does not belong 
to this newsgroup.

> but giving
> _optional_ ID to threads and packing execution contexts (with bonus
> effect of already solved scope) in procedures is not?? GMaB.

That's the point. It's OK to disagree (but then, repeat the small 
exercise I've described before - the one with if/else statement).


>   Do you say, right now, that "context in which mutex is locked" is an
> resource??

The ability to execute within the critical section of code is a resource 
that exists in one unit. Call it "token" or whatever. That's resource 
for me. You can get it and you can give it away.


>   You are probably spending lots of time just defending your current
> positions, flaming and patronizing on your way :).

Not really. Currently, you're the only one who is against. ;)

> Why don't finish
> this design so we can see where clean and pure library approach kicks
> in with condvar handling? :) Would you use "l" or "m" to pass mutex as
> an argument to "wait"?

It would be *really* better if you knew existing practice w.r.t. 
threading in C++. But you have excellent intuition :)
Here's how Boost.Threads does it:

http://www.boost.org/doc/html/condition.html#id231704-bb

Yes, it's about passing locker as an argument to condvar.wait().
I don't have anything against it.

> Threading and locking I would solve with
> syntactic sugar, and condvar handling with library calls.

OK. I mean - I understand that your favourite way of threading looks 
like this.

My thought is that synchronization is supported at the libary level 
(threads synchronize using objects, which should reuse established 
practice w.r.t. to resource management), but the core fact of stating 
concurrency is done at the level of control statements.

It's normal to have different tastes (and there's no point rolling over 
endless discussions about them), but I would like to know if there are 
any obvious mistakes and dangers in what I wrote.

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

.

0