January 2006 - Boost - lists.boost.org

Multi-lock semantics?
by Preston A. Elder 02 Jan '06

02 Jan '06

Hey all, What happened to the multi-lock semantics? I had expected by now to see something like: // Takes two mutexes as arguments, locking them in a pre-defined order // (ie. lowest ptr first). Blocks until both locked. boost::mutex::dual_scoped_lock // Same as above but recursive. boost::recursive_mutex::dual_scoped_lock // Same as boost::mutex::dual_scoped_lock, however if one cannot be // acquired, both are released (ie. the first is unlocked again). boost::try_mutex::dual_scoped_lock // Same as above but recursive. boost::recursive_try_mutex::dual_scoped_lock // Same as boost::mutex::dual_scoped_lock, however if both can't be // acquired in the specified time limit, both are released. boost::timed_mutex::dual_scoped_lock // Same as above but recursive. boost::recursive_timed_mutex::dual_scoped_lock I assume that a dual_scoped_lock would then have a first() and second() member that would yeild the underlying scoped_lock for the first-locked and second-locked mutex (from which you could compare the mutex it locks to one of your mutexes and figure out which was locked first). Similarly, it would be nice to say, have a 'multi' version of the above for an arbitary number of locks (and an appropriate operator[] rather than first() and second()). We all know the old thing about the way to avoid deadlocks is to acquire them in the same order, and the threads FAQ says some kind of way to do this without the ugly syntax that is in the FAQ being necessary (see http://www.boost.org/doc/html/threads/faq.html#id2786718 and the code segment below which includes implementing such wise advice). I'm sure I could knock something that implements the above (at least for dual) in not too long, implementing something for multi would be harder (though I immagine someone who is familiar with how boost::function works might not have a tough time making an equivalent for mutex locking). Anyway, anyone want to get on to this? -- PreZ :) Death is life's way of telling you you've been fired. -- R. Geis

2 2

PP re-entrancy question
by Arkadiy Vertleyb 02 Jan '06

02 Jan '06

Hi, The typeof library defines a macro, REGISTER_TEMPLATE, that is intended for use by the library users. Once people started using the library, they eventually wanted to use this macro inside the Boost PP looping constructs, such as SEQ_FOR_EACH, etc. Since the implementation of REGISTER_TEMPLATE itself uses quite a few looping constructs, people ran into re-entrancy issues. I would like the users to be able to use the macro with whichever looping construct they prefer, and, AFAIU, the easiast (only?) way to achieve this would be to limit the macro implementation to only use automatically re-entrant macros, such as BOOST_PP_REPEAT. Is this the right way to go for this particular case, and generally for any macro that is in the library interface? Thanks, Arkadiy

2 5

[asio] simple coroutine lib.
by Giovanni P. Deretta 01 Jan '06

01 Jan '06

I'm posting this under the asio header because it depends heavily on asio... I've uploaded in the vault a simple coroutine lib. Only works under unix though, but windows support could be added by some one with more knowledge than me of win32 fibers. In pratice the coroutine lib allow the creation of separate user contextes, and provides functions that return functors that when called reactivate the coroutine. This functors can be provided as callbacks to asio asynch functions. There is still a lot of work to do before the lib becomes actually useful, but it is quite good for just a weekend conding project. Plese, critique and comment :) --- Giovanni P. Deretta

2 2

Error w/ wave/cpp_exceptions.hpp?
by Kon Lovett 01 Jan '06

01 Jan '06

Shouldn't wave/cpp_exceptions.hpp be 373c373 < char const* get_related_name() const --- > char const* get_related_name() const throw() Best Wishes, Kon

2 1