http://code.activestate.com/recipes/tags/synchronization-multithreading/2010-04-08T04:36:05-07:00ActiveState Code Recipes2010-04-08T04:36:05-07:00Mateyuzohttp://code.activestate.com/recipes/users/4172453/http://code.activestate.com/recipes/577180-decoupled-proxy-of-a-state-bearing-object-in-a-mul/

<p style="color: grey"> Python recipe 577180 by <a href="/recipes/users/4172453/">Mateyuzo</a> (<a href="/recipes/tags/access/">access</a>, <a href="/recipes/tags/multiprocessing/">multiprocessing</a>, <a href="/recipes/tags/process/">process</a>, <a href="/recipes/tags/processing/">processing</a>, <a href="/recipes/tags/subprocess/">subprocess</a>, <a href="/recipes/tags/synchronization/">synchronization</a>, <a href="/recipes/tags/syncmanager/">syncmanager</a>, <a href="/recipes/tags/threading/">threading</a>, <a href="/recipes/tags/__getattribute__/">__getattribute__</a>). Revision 2. </p> <p>Describes a simple example of the potential for shared Singleton or Borg object methods to be proxy'd by an object that SyncManger can present to requesting subprocesses.</p>

2008-09-08T08:29:14-07:00Anandhttp://code.activestate.com/recipes/users/760763/http://code.activestate.com/recipes/576418-multithreaded-fifo-gate/

<p style="color: grey"> Python recipe 576418 by <a href="/recipes/users/760763/">Anand</a> (<a href="/recipes/tags/semaphores/">semaphores</a>, <a href="/recipes/tags/synchronization/">synchronization</a>, <a href="/recipes/tags/system/">system</a>, <a href="/recipes/tags/threading/">threading</a>). Revision 5. </p> <p>While programming with multiple threads, sometimes one needs a construct which allows to suspend the execution of a set of running threads. This is normally required by an outside thread which wants to suspend the running threads for performing a specific action. The threads need to resume after the action in the same order in which they got suspended. </p> <p>A thread gate (or gateway) allows you to do this. It acts like a gate through which only one thread can pass at a time. By default the gate is open, allowing all threads to "enter" the gate. When a thread calls "close", the gate is closed, blocking any threads which make a further call to "enter", till the gate is re-opened by the owner, whence the threads resume the order in which they got blocked.</p> <p>The real-life parallel for this is a human operated level cross, which allows only one vehicle to pass at a time.</p>