Boost logo

Boost :

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
> > the locks duration (an analogous example would be "reset" on the
> > pointers):
> Agreed. But I would recommend two methods, "acquire" and
> 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(...);

  // ...


  // ...

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
> > thread unsafe (or offers a lower guarantee - see smart pointers
> > 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*.



Boost list run by bdawes at, gregod at, cpdaniel at, john at