Subj : Re: Thoughts about threads in C++
To   : comp.programming.threads
From : Jomu
Date : Sun May 01 2005 03:07 am


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

  Does that mean I can't design languages, libraries and/or features,
nor do threading at all?

  Sorry, I didn't know. :( :)

> Anyway, here's the short story:
>
> The RAII idiom is the most basic and fundamental idiom in C++ - it is


  Thanks for nice explanation, but I do hit Google first moment I see
unknown acronym ;).

> 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

  This is so improvisation and too-much-information and
what-is-this-for that it hurts my eyes - really. Explicitly naming
locking scope (ops, that's even an object there) is ok, but giving
_optional_ ID to threads and packing execution contexts (with bonus
effect of already solved scope) in procedures is not?? GMaB.

  RAII can be "established" in C++, but obligatory finalization
techniques were there before C++, and structured programming also was.
I do like to have my contexts very explicit and visible as in:

  LOCK mutex DO
    ...
  END;

  or

  synchronized (mobj) {
  }

  Compared to this, using RAII for locking is almost pythonesque. To
invent new object to hold scope in goes beyond it :).

  I do understand a need for RAII in language without garbage
collection like C++, but let it stay there, at obligatory freeing of
resources.

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

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

  It is no more resource than execution context is. Nor less.

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

  I didn't see RAII used for threading part. But ok, I am not C++worthy
:).

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

  Languages are not designed like that. Or they shouldn't be, at least.
That leads to fantastic mixups of idioms, paradigms, philosophies...
you name it.

  You are probably spending lots of time just defending your current
positions, flaming and patronizing on your way :). 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"?

  I am looking forward to final - there is no mix! :)

  "region" is no more foreigner than your threading addon is, and no
more different than current scoping in C++. It's also very much like
your primary addon. If I was you, I would solve all this without RAII,
using two "extremes". Threading and locking I would solve with
syntactic sugar, and condvar handling with library calls. rwlock would
fall with standard locking and more exotic things would go library
also.

  I will see to implement something like your threading syntax as
addendum to current threading method in our in-house tools.

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

  dd

.