By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
424,963 Members | 924 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 424,963 IT Pros & Developers. It's quick & easy.

How can I implement this with boost::thread?

P: n/a
Hello,

I would like to re-implement this function that currently uses
pthreads:

pthread_mutex_t mutex;
int i = pthread_mutex_init(&mutex, 0);

void MutexCB(int lock)
{
if (lock)
pthread_mutex_lock(&mutex);
else
pthread_mutex_unlock(&mutex);
}

using the boost library.

So the function has to lock the mutex if 'lock' == true, unlock it
otherwise. It has to be thread safe as well.

I had difficulties since the scoped_lock is NOT thread safe, and the
access to the mutex's do_lock()/do_unlock() methods is private.

Regards,
Petru
P.S. Here is a solution I found. It uses:
- recursive mutex,
- a static lock that gives the access to the lock/unlock mechanism (no
d-tor call during the operations) and
- another lock (on the stack) that makes the static lock thread safe.

boost::recursive_mutex m;

void MutexCB(int lock)
{
boost::recursive_mutex::scoped_lock l(m); // it makes the 's'
lock thread safe
static boost::recursive_mutex::scoped_lock s(m, false /*lock
later only if necessary*/);
if (lock)
s.lock();
if (!lock)
s.unlock();
}

As you can see it is more complicated that the pthread solution. is
there possible to write a solution at least as simple as the pthreads
one?

Jun 15 '07 #1
Share this Question
Share on Google+
5 Replies


P: n/a

<pe*************@gmail.comwrote in message...
Hello,
I would like to re-implement this function that currently uses
pthreads:
[snip]
using the boost library.

So the function has to lock the mutex if 'lock' == true, unlock it
otherwise. It has to be thread safe as well.
I had difficulties since the scoped_lock is NOT thread safe, and the
access to the mutex's do_lock()/do_unlock() methods is private.
Regards, Petru
'Boost library' and 'pthread' are off-topic in this NG (at this point in
time.).
Do you have a standard C++ question?
Also, see this FAQ for guidelines on posting:

http://www.parashift.com/c++-faq-lite/how-to-post.html

--
Bob R
POVrookie
Jun 15 '07 #2

P: n/a
On Jun 16, 1:39 am, "BobR" <removeBadB...@worldnet.att.netwrote:

[...]
'Boost library' and 'pthread' are off-topic in this NG (at
this point in time.).
Pthreads, maybe, but Boost, certainly not. Boost is certainly
C++, and it is not platform specific, so it is on topic.
Do you have a standard C++ question?
And what was the topic of discussion here before 1998? Or has
the charter been radically changed since then?

--
James Kanze (Gabi Software) email: ja*********@gmail.com
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34

Jun 16 '07 #3

P: n/a

James Kanze wrote in message ...
On Jun 16, 1:39 am, "BobR" wrote:

/* """ quote
[...]
'Boost library' and 'pthread' are off-topic in this NG (at
this point in time.).
Pthreads, maybe, but Boost, certainly not. Boost is certainly
C++, and it is not platform specific, so it is on topic.

""" */ unquote

COOL, then wxWidgets CAN be discussed here. <G>

..... wait... <putting on flame suit... OK, Let 'er fly.

To OP: Ooops, sorry.
--
Bob R
POVrookie
Jun 16 '07 #4

P: n/a
On Jun 16, 6:27 pm, "BobR" <removeBadB...@worldnet.att.netwrote:
James Kanze wrote in message ...
On Jun 16, 1:39 am, "BobR" wrote:
/* """ quote
[...]
'Boost library' and 'pthread' are off-topic in this NG (at
this point in time.).
Pthreads, maybe, but Boost, certainly not. Boost is certainly
C++, and it is not platform specific, so it is on topic.
""" */ unquote

COOL, then wxWidgets CAN be discussed here. <G>
Technically, I think so.

Boost, at any rate, is certainly admissible, since it is more or
less and antechambre for standardization, and it is (like the
entire language) very low level.

I think that the actual charter also would accept things like
wxWidgets. It's hard to say whether that was the intent,
however, since such libraries didn't exist at the time.
Existing portable class libraries, such as the Booch components
or USL, were certainly considered acceptable.

Arguably, even MFC is acceptable, because there was, at one
time, and implementation of it for Unix. Practically, I'd argue
that the intent never really included commercial libraries,
however.

At any rate, I'd certainly accept Boost, and pthreads or Windows
threads would be acceptable in the framework of a more general
discussion on thread safety issues (e.g. as an example).
Details discussion of the more subtle aspects of their
interface, of course, is better handled in other forums; Boost
has their own list, and there are dedicated groups for pthreads
and Windows. In the case of Boost, however, I'd say that the
main reason is because that's where the poster is more likely to
get a knowledgeable response, not because it's strictly off
topic here.

--
James Kanze (Gabi Software) email: ja*********@gmail.com
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34

Jun 16 '07 #5

P: n/a
This is the answer I've got on the boost threads group:
http://lists.boost.org/threads-devel/2007/06/0202.php

Regards,
Petru

Jun 27 '07 #6

This discussion thread is closed

Replies have been disabled for this discussion.