boost::thread locks

[Lars Uffmann]

Hi everyone,

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?

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.

And with different code paths for the first usage, I cannot just create
it upon first need for a lock and then unlock / lock it later.

Any idea? Wasn't able to find anything in the boost::thread docs at
http://www.boost.org/doc/html/thread/concepts.html#thread.concepts.lock-concepts

All the locks there say for the constructor:
Constructs an object lk, and associates mutex object m with it, then
calls lock()

Thanks in advance!

Lars

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

 

[Eric.Malenfant]

Hi everyone,

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?

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.

And with different code paths for the first usage, I cannot just create
it upon first need for a lock and then unlock / lock it later.

Any idea? Wasn't able to find anything in the boost::thread docs athttp://www.boost.org/doc/html/thread/concepts.html#thread.concepts.lo...

All the locks there say for the constructor:
Constructs an object lk, and associates mutex object m with it, then
calls lock()

Is this what you're looking for?
"L lk(m,b); Constructs an object lk, and associates mutex object m
with it, then if b, calls lock()"
http://www.boost.org/doc/html/thread/concepts.html#thread.concepts.ScopedLock

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

I will not comment about the on or off-topic-ness here, but this would
have been definitely on-topic on the boost-users mailing list.
http://www.boost.org/more/mailing_lists.htm#users

 

[Lars Uffmann]

Is this what you're looking for?
"L lk(m,b); Constructs an object lk, and associates mutex object m
with it, then if b, calls lock()"
http://www.boost.org/doc/html/thread/concepts.html#thread.concepts.ScopedLock

Yes, I feel stupid now. Thanks for pointing me to what I failed to see
having it right in front of my nose.

I will not comment about the on or off-topic-ness here, but this would
have been definitely on-topic on the boost-users mailing list.

Yes, definitely on-topic there, but as I said - it's a mailing list, but
mailing lists start to get crowded when a critical mass of users is
reached, which is when they should become newsgroups... Anyways, since I
was told boost was created standard-conform, and that boost will
hopefully be in a future C++ standard, I will try to keep boost
_usage_-discussions to c.l.c++

Thank you for your help!

Lars

 

[Boris]

[...]Yes, definitely on-topic there, but as I said - it's a mailing
list, but mailing lists start to get crowded when a critical mass of
users is reached, which is when they should become newsgroups...
Anyways, since I

You can read the Boost mailing lists in your newsreader via
news.gmane.org. I find it also more comfortable this way.

Boris

 

[Lars Uffmann]

Hi Boris,

You can read the Boost mailing lists in your newsreader via
news.gmane.org. I find it also more comfortable this way.

Yes, I am reading the news portal of the mailing list. However, I found
that posting this way(*) is not possible. Or I would use the list for
questions referring to boost.

Best Regards,

Lars

* Happy to be proven wrong

 

[Gerhard Fiedler]

Yes, I am reading the news portal of the mailing list. However, I found
that posting this way(*) is not possible. Or I would use the list for
questions referring to boost.

Many lists require you to have subscribed to the list in order to be able
to post. The process with gmane.org in this case is:

- subscribe to the list you're interested in
- disable email delivery (but remain subscribed)
- read the list through gmane.org
- when posting through gmane,org, use the email you used for subscribing in
the From header
- the first time, you'll get an email from gmane,org asking for
confirmation of your email address

Works for me with a few such lists (not specifically the boost list,
though).

Alternatively, you may be able to set up your newsreader so that a reply in
that gmane,org newsgroup automatically uses email to the mailing list
address. You read through gmane,org, but post through email.

Gerhard

 

[Lars Uffmann]

Many lists require you to have subscribed to the list in order to be able
to post. The process with gmane.org in this case is:
> [...]

Ho-humm... point taken. I wished there wasn't so many different
approaches to such simple things as discussion forums

Thanks, I'll try that - either this week or after my next business trip!

Best Regards,

Lars

 

[James Kanze]

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.

 

[Lars Uffmann]

Hello James,

Simple answer: no.

Actually, further up in the thread I got a different answer and it worked
Constructing the lock with
boost::mutex::scoped_lock sl (someMutex, false);
does what I wanted to do - second parameter states whether or not to
acquire a lock upon construction or not.

Thanks anyways & have a nice day!

Lars