Hi there, o.k., being a physicist, I hope I can find the right words in this computer-scientist-rich environment ;-) Imagine an environment where m entities produce items ("producers") which are processed by n workers ("consumers"), running as threads. The results are then returned back to the original entities, which themselves run in threads. Both m and n are not known in advance, as it is the user (or an automated procedure) that determines how many producers and consumers there will be. In the middle of this sits a broker, which takes care of all communication between producers and consumers. Both need to register with the broker before being able to communicate with each other. I want to have as few restrictions for my users as possible, as I want my library to be easy to use. Hence there is no rule when producers and consumers may or may not be registered. However, my current setup makes it desirable that consumer threads do not *start* before at least one producer has been registered (they are started by the broker). Hence I need to have a mechanism that blocks all consumers that have been registered before the first producer, until such time that the first items to be processed are available. If the number of consumer threads would be known in advance, Boost's Thread-Barrier might be a possible choice. As I do not know this number, however, I'll probably have to do my own locking (see my sample implementation). Best, Ruediger Zeljko Vrba wrote:

On Wed, Aug 06, 2008 at 01:36:19AM +0200, Ruediger Berlich wrote:

...

I'm trying to find a way to let a number of threads start execution simultaneously, and in any case not before a certain condition has come true.

Define "simultaneously". If you have more threads than CPUs, it should be obvious that, due to time-slicing, it is physically impossible that they start simultaneously. Even with more CPUs than threads, this is achievable only in architecture-specific way and with instructions that are accessible only to supervisor-level code (e.g. Pentium's MONITOR instruction or broadcasted interprocessor interrupt -- if the latter exists at all). Every other mechanism will incur some delay between start of different threads.

...

I also believe I do not have to use a condition variable, as the different threads need to synchronize their access to a data ressource anyway, and I can use the same mutex to block them in the beginning.

While one thread is in the critical section protected by the mutex, all others will wait until that thread exits the critical section. This is hardly "simultaneous" start.

...

One of the problems (which seems to be unrelated to the code below) is that the three threads do not get called equally often. In one run, one thread was called 14564 times, another 1607 times and the third one 8676 times.

This is perfectly normal, and is not a "problem". Threaded code that depends on relative speeds of threads (on a general-purpose OS) is calling for trouble.

Can you describe what are you trying to achieve? Threads might not be the best solution..

-- Kind Regards / Mit freundlichen Gruessen, Ruediger Berlich ------------------------------------------------------------------------ Dr. Ruediger Berlich | E-mail: ruediger.berlich@iwr.fzk.de Forschungszentrum Karlsruhe | Web: http://ruediger.berlich.com Steinbuch Centre for Computing | Phone: +49 (0)7247 825678 Hermann-von-Helmholtz-Platz 1 | Fax: +49 (0)7247 824972 D-76344 Eggenstein-Leopoldshafen | Mobile: +49 (0)178 5567842 ------------------------------------------------------------------------ /*************************************************************************/ The Steinbuch Centre for Computing of Karlsruhe Institute of Technology (the Cooperation of Forschungszentrum Karlsruhe GmbH and Universitaet Karlsruhe TH) will run its annual GridKa School from September 8th to 12th, 2008. Please find further information at http://www.fzk.de/gks08 . /*************************************************************************/ Forschungszentrum Karlsruhe GmbH Sitz: Weberstraße 5 76133 Karlsruhe Amtsgericht Mannheim HRB 100302 Vorsitzende des Aufsichtsrats: Baerbel Brumme-Bothe Vors. der Geschäftsführung: Prof. Dr. Eberhard Umbach

I wrote the following to do some volume testing on a service, may help you: boost::mutex mutex; bool testthreads( std::string& mdoid, std::vector<unsigned char>& userpin ) { boost::mutex::scoped_lock lock( mutex );//wait for the main thread to say go lock.unlock();//release mutex immediately to allow other threads to start performOp(); return true; } bool testmultithreaded() { printf( "Please enter thread count [1-2048] : " ); std::string input; std::cin >> input; unsigned long encCnt = std::strtoul( input.c_str(), NULL, 0 ); if( encCnt == 0 || encCnt > 2048 ) { printf( "Thread count out of range" ); return false; } const int threadCnt = encCnt; std::vectorboost::thread> threads; boost::timer t; boost::mutex::scoped_lock lock( mutex );//lock the mutex to stop threads from starting for( int i = 0; i < threadCnt; ++i ) { threads.push_back( boost::shared_ptrboost::thread( new boost::thread ( boost::bind( &testthreads, mdoid, userpin ) ) ) ); } double threadscreated = t.elapsed(); lock.unlock();//start the threads off for( int i = 0; i < threadCnt; ++i ) { threads[i]->join();//wait for each thread to finish } double threadsFinished = t.elapsed(); boost::mutex::scoped_lock hmilock(hmiMutex); printf( "%lu threads completed\n", encCnt ); printf( "Threads created in %f seconds\n", threadscreated ); printf( "Threads completed in %f seconds\n", threadsFinished - threadscreated ); return true; } ****************************************************************************** "This message and any attachments are solely for the intended recipient and may contain confidential and privileged information. If you are not the intended recipient, any disclosure, copying, use, or distribution of the information included in this message and any attachments is prohibited. If you have received this communication in error, please notify us by reply e-mail and immediately and permanently delete this message and any attachments. Thank you." Interactive Transaction Solutions Ltd (2473364 England) Registered Office: Systems House, Station Approach Emsworth PO10 7PW ********************************************************************** Ce message �lectronique contient des informations confidentielles � l'usage unique des destinataires indiqu�s, personnes physiques ou morales. Si vous n'�tes pas le destinataire voulu, toute divulgation, copie, ou diffusion ou toute autre utilisation de ces informations, est interdite. Si vous avez re�u ce message �lectronique par erreur, nous vous remercions d'en avertir son exp�diteur imm�diatement par email et de d�truire ce message ainsi que les �l�ments attach�s. Interactive transaction Solutions SAS- France (RCS Pontoise : 489 397 877) Si�ge social : Parc Saint Christophe, 10, Avenue de l�Entreprise 95865 Cergy-Pontoise Cedex ______________________________________________________________________ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email ______________________________________________________________________

On Wed, Aug 06, 2008 at 10:53:43AM +0200, Ruediger Berlich wrote:

will be. In the middle of this sits a broker, which takes care of all communication between producers and consumers. Both need to register with the broker before being able to communicate with each other.

Having a single broker for all communication between producers and consumers defeats the point of having threads. Eventually, the broker will become the bottleneck (serialization point). Or did I misunderstand the first sentence?

has been registered (they are started by the broker). Hence I need to have a mechanism that blocks all consumers that have been registered before the first producer, until such time that the first items to be processed are available.

Condition variable?