Re: boost::thread locks
On Mar 14, 1:28 pm, Lars Uffmann <a...@nurfuerspam.de> wrote:
Simple question: Is there a lock object in boost::thread that
I can associate with a boost::mutex upon creation, but which
doesn't try to acquire a lock until I explicitely tell it to?
Simple answer: no. This is a well known problem with Boost
threads. There are cases where you need to explicitly manage
the lifetime of the lock. (One frequent case is where the lock
should be freed by the deleter of a shared_ptr.)
About the only work around is to use a dynamically allocated
lock, managed by a smart pointer. Or to simply modify the Boost
sources so that they do the right thing. (It's a simple matter
to give the lock/unlock functions of mutex public access.)
FWIW: the current draft of the next version of the standard
doesn't have this problem.
Namely, I wish to acquire a lock and release it multiple times
in a function, but always on the same mutex - somehow it seems
not sensible to always create a new lock and delete it
afterwards.
Why not? More generally, it sounds very much like you're doing
too much in the function.
[...]
PS: Please refrain from replies about being off-topic, usage
of boost is very on-topic in my eyes and there is no boost
newsgroup, just a mailinglist with a news-like (read only)
portal
No problem. Threads are very much part of C++, regardless of
what some people think. In this case, about the only rationale
for saying that Boost threads are off topic is that the
threading model being adopted by the committee is significantly
different. But still closer to Boost than to much of the other
junk you'll find out there---Boost::threads may have some
conceptual problems, but at least it works.
--
James Kanze (GABI Software) email:james.kanze@gmail.com
Conseils en informatique orient=E9e objet/
Beratung in objektorientierter Datenverarbeitung
9 place S=E9mard, 78210 St.-Cyr-l'=C9cole, France, +33 (0)1 30 23 00 34