How can I implement this with boost::thread?

[petru.marginean]

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?

 

[BobR]

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

 

[James Kanze]

[...]

'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?

 

[BobR]

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.

 

[James Kanze]

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.

 

[petrum]

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

Regards,
Petru