Boost logo

Boost :

Subject: Re: [boost] [thread] countdown_latch
From: Michael Marcin (mike.marcin_at_[hidden])
Date: 2013-04-22 04:16:19

On 4/21/2013 11:30 PM, Vicente J. Botet Escriba wrote:
> ++ It reduce the size of the widget.
> - dangling reference (but that can be mastered.

It also allows latch to be forward declared and latch mutex and
condition variable are only defined in the source file.

Do mutexes and condition variables take up system resources other than
plain memory? Can they be exhausted?

If it's just a small amount of memory on a not-often instantiated class
I guess it's not worth the oddity of a dangling reference. Although a
latch member is a bit silly if it can never be reset.

> I don't know your constraints:
> Why do you need to run the setup on the new created thread?
> Could it be executed directly on the widget constructor?
> If yes

Maybe it's time to get a bit more concrete.
In the real scenario widget is a win32_window which wants to run its
message pump in a worker thread.

A win32 message queue must run on the thread that created the window
hence setup must happen on the thread.

> Do you need to manage the thread? if not, detaching the thread allows
> you to don't include it on the widget context.

I post a quit message and join in the destructor.

Thanks for your input.

Back on topic of latches and barriers.
I was reading up on Java's CyclicBarrier and found its await return
value pretty interesting and probably fairly free to implement.

"...each invocation of await() returns the arrival index of that thread
at the barrier."

"the arrival index of the current thread, where index getParties() - 1
indicates the first to arrive and zero indicates the last to arrive."

To do this in boost::thread::barrier you would just have to cache
m_count right after the decrement and return it instead of the current

Boost list run by bdawes at, gregod at, cpdaniel at, john at