Boost C++ Libraries: Ticket #4725: Synchronisation and shared mutex's Get total_count

dominicstreeter@… — Sun, 10 Oct 2010 15:39:53 GMT

I have written into the Boost file "condition_variable.hpp" a function to perform the correction. Details on this can be found easily here.

http://www.gamedev.net/community/forums/topic.asp?topic_id=584562

Thank you for your time

EnlightenedOne

component changed

viboes — Sat, 27 Nov 2010 16:57:48 GMT

component threads → thread

dominicstreeter@… — Sat, 27 Nov 2010 18:13:14 GMT

I wish to close this ticket on the grounds that the above code is flawed and a work around the problem faced here requires a seperate class to encapsulate a count of the total threads being used. Although there is no method for getting the total threads locked in a barrier from the class you can encapsulate this functionality in your own class outside of a barrier class and pass in the expected total threads to be waiting from there.

To explain what the barrier class that encapsulates/replaces this mechanism actually ended up looking like here is a rough abstract of my working barrier.

boost::mutex mutAccessData;

boost::condition_variable_any multiThreadLink;

int intThreadsCaughtCount;

You pass in the number of threads registered to be waiting with the scene if they are all waiting on the barrier you wake them up and return true signalling success to a managing thread that might be waiting for all of them to be at the barrier.

bool getWakeUpIfAllReady(int intThreadsHandledByObject) {

bool boolIsAwoken;

mutAccessData.lock();

if (intThreadsCaughtCount == intThreadsHandledByObject) {

multiThreadLink.notify_all();

boolIsAwoken = true;

} else {

boolIsAwoken = false;

}

mutAccessData.unlock();

return boolIsAwoken;

}

This is called by threads that need to wait until they are woken up.

void waitUntilAllReady() {

mutAccessData.lock();

intThreadsCaughtCount++;

multiThreadLink.wait(mutAccessData);

intThreadsCaughtCount--;

mutAccessData.unlock();

}

There were one or two scenarios where the rewritten get total threads might be useful for handling complex state logic for a shutdown during an erroneous event; however even that use has alternate work arounds which I have used now. Therefore I wish to retract my ticket.

Perhaps a boost class to encapsulate this behaviour might be of value? If not this would be a useful exercise to do for an example in the boost documentation on threading for newcomers. Anyway thank you for your time :)

viboes — Fri, 30 Dec 2011 23:17:57 GMT

Replying to dominicstreeter@…:

There were one or two scenarios where the rewritten get total threads might be useful for handling complex state logic for a shutdown during an erroneous event; however even that use has alternate work arounds which I have used now. Therefore I wish to retract my ticket.

Perhaps a boost class to encapsulate this behaviour might be of value? If not this would be a useful exercise to do for an example in the boost documentation on threading for newcomers. Anyway thank you for your time :)

Hi,

It would be great if you may write the text to be added to the tutorial.

Vicente

status changed; resolution set

viboes — Sat, 07 Jan 2012 23:46:45 GMT

status new → closed
resolution → worksforme

Closed as requested.