On Feb 26, 4:15 pm, Jeff Schwab <[EMAIL PROTECTED]> wrote: > [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-. > > 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?- Hide quoted text -
Extremely promising! You could even have a subclass of FutureTask enqueue itself to ExecutorService executor. You could have different models of execution too, such as initializing with a priority, scheduling conditions, etc. The exact implementation is a little suspicious: does ExecutorService run in its own thread, and callback FutureTasks in order, or in some order? Python can do the same thing too. -- http://mail.python.org/mailman/listinfo/python-list
