Re: RFC: Multithreading design constraints

From: Miki Jovanovic (miki_at_[hidden])
Date: 2000-06-05 10:00:05

First... John Maddock, great effort! I started writing identical 
document, but I see you beat me to it. No matter. All we need is a 
starting point for discussion, and this is what we got. Lets start...

--- In boost_at_[hidden], scleary_at_j... wrote:
> > Issue 4:
> > Dangling braces:
> > The main problem with the scoped guard object is that the extent 
of the
> > lock may not coincide with the extent of the scope
> >    ...
> > Solution: add an "acquire" method to the guard object that lets
us 
control
> > the locks duration (an analogous example would be "reset" on the 
smart
> > pointers):
> 
> Agreed.  But I would recommend two methods, "acquire" and
"release", 
rather
> than just "acquire" with a boolean parameter.

People! People! Wait... Huh. This has suprised me greatly. First, I 
have never tried to reduce readibility of my code for the sake of 
beginners. Not to say that we should not care for them, but how about 
a simple comment?

int main() {
  { // sync scope
    lock_type::guard g(...);

    ...
  }
}

Isn't this easier, more elegant, less intrusive etc. The number of 
places there the sync scope will correspond with a natural scope is 
far greater then having to artificially change the interface.

This said, I do support having both acquire and release(), but only
to allow manipulation for complex scopes. So actually, a majority of 
shorter then scope cases can be written like:

int main() {
  lock_type::guard g(...);

  // ...

  g.release();

  // ...
}

Otherwise, I am casting a strong vote for a simple scope for normal 
usage. Unless one needs very specialised/optimised synchronisation, 
the only thing we should have to do a put a single line at the 
beginning of our code. Why should I put an acquire(), then if..else, 
and finally throw, if all I need is a simple lock?

> > Issue 6:
> > Generic thread coding:
> > One common idiom may be to add a "threaded" bool template 
parameter to
> > template classes, when true the object is thread safe, when false 
its
> > thread unsafe (or offers a lower guarantee - see smart pointers 
for
> > example).
> 
> Then have the default value be BOOST_MT?  Just a thought :)

I think a define is a better way to go as well. Generally, I think 
that directing implementation details from template parameters is a 
bad idea. Sure it is powerful, but it will soon bloat the template to 
unusability. Multithreading is not the only implementation issue. 
People started putting memory allocators there, then someone will 
think of another convinience... All of a sudden a simple shared_ptr 
will have 10 parameters, where it was supposed to be *simple*.

Cheers,

Miki.