[EMAIL PROTECTED] wrote: > On Feb 26, 12:42 pm, Jeff Schwab <[EMAIL PROTECTED]> 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? -- http://mail.python.org/mailman/listinfo/python-list
