Re: [boost] [thread] countdown_latch

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 
true/false.