is there enough information?

[castironpi at gmail.com]

On Feb 26, 4:15 pm, Jeff Schwab <j... at schwabcenter.com> wrote:
> castiro... 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-.
> > 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.