is there enough information?

Jeff Schwab jeff at schwabcenter.com
Tue Feb 26 23:15:32 CET 2008


castironpi at gmail.com wrote:
> On Feb 26, 12:42 pm, Jeff Schwab <j... at schwabcenter.com> wrote:
...
>>>>> th1       th2
>>>>> set cmd
>>>>>           run cmd
>>>>> get result
>>>>>           acknowledge
>>>>> continue  continue

>>>>> th2 won't -run cmd- until th1 completes -set cmd-.  th1 won't -get
>>>>> result- until th2 completes -run cmd-.  and once -acknowledge-
>>>>> completes, both can go about their merry ways.

>>>> That is exactly the kind of case where semaphores are usually used.
>>>> Thread1 can "fill" the semaphore when the command is ready, then Thread2
>>>> can "empty" the semaphore once it has finished running the command.

> I want to awaken -that- -specific- -thread-.
> 
> Semaphore acquire: "The implementation may pick one at random."
> Lock acquire: "which one of the waiting threads proceeds is not
> defined"
> Event set: "All threads waiting for it to become true are awakened"
> Condition notify: "This method wakes up one of the threads waiting"
> Condition notifyAll: "Wake up all threads waiting on this condition"
> 
> I will contend it's impossible without a specialization.  Certainly an
> array of semaphores could fit the bill; is that what you were
> suggesting?

A collection of semaphores could well be the right solution.  Actually, 
I'm getting the feeling that you want something like a Java Futures:

http://java.sun.com/j2se/1.5.0/docs/api/java/util/concurrent/Future.html

Does that sound promising?



More information about the Python-list mailing list