Boost logo

Boost :

From: Vygis D. (vygintas.daugmaudis_at_[hidden])
Date: 2003-10-20 19:59:03


Besides, speaking of Boost.Threads, I have tried to implement some
equivalent to javaish

synchronized(obj) {}

and results are:

    template<typename T, typename Mutex = boost::mutex>
    synchronized;

    P.S.
    lighweight_mutex cannot be supported. 2nd template parameter must be a
model of Mutex or its refinement.

Example:

    synchronized<my_class> a; // a is shared between multiple threads

    let's say, my_class has a method ::test(),

    so: a->test() would be a synchronized call to test()

    P.S. Constness is kept
    const synchronized<my_class> a;
    a->test(); call will not be allowed if test() method is modifying.

even further:
    synchronized< std::vector<int> > s_vect;

    every method invoked, a la

    s_vect->push_back(<some value>);

    will also be synchronized.

As synchronized template models pointer to object, it is possible to use
boost::bind with synchronized objects:
    boost::bind(&std::vector<int>::push_back, s_vect);
    As a result, functors from synchronized<> objets are also thread-safe.

And good news, even msvc++ 6.0 is able to compile this hocus phocus.

We surely don't need synchronization all the time (I can already hear some
of you screaming about performance issues, etc.<g>)
    so there we have:
    (*s_vect).begin(); etc.

BTW, matter of habits and/or taste, but this syntax looks definitely
informative for me (*you're about to leave your safe synchronized world
<g>).

Type traits are also important as well. This problem was solved with
synchronized_traits template struct which can be explicitly specialized to
fit one's needs.

Well... what more to say...

I don't know whether I'm just being a noise, just repeating things that have
been said already. I happen to think that even reinventing the wheel may be
constructive because idle hands are playground of evil :)

So, is there any interest in such a facility?

Digitally Yours,
Justinas Vygintas D.


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk