[concurrency-interest] is choice beteen asynchrone/synchrone methodan implementation detail?

Dhanji R. Prasanna dhanji at gmail.com
Wed Jul 26 01:11:29 EDT 2006


On 7/26/06, Peter Veentjer <alarmnummer at gmail.com> wrote:
> The point I'm trying to make is that the choice of
> synchrone/asynchrone is not an implementation/configuration detail,
> but part of the definition of the function. And if I understand you
> correctly, you agree :)

Yes, I suppose I do. =)

>
> How you are going to implement the asynchrone call (after you know the
> call is asynchrone) is just a configuration/implementation detail.
>

Afai concerned it is poor documentation that does not make clear what
the method is expected do. ;)

> >
> > Java is strict evaluative so it does not make sense to talk about
> > method-granular promises. All methods evaluate to values, period.
> Not void methods. These are the functions you 'could' make asynchrone
> without anyone knowing.
>

I disagree, because making them asynchronous if the contract reports
otherwise is fallacious and may break lexical guarantees. To take your
own example:

public interface CookableFood {
/**
  * When this method returns food is cooked
  */
  public void cook();
}

//usage scenario:
CookableFood c = CookerFactory.getMisbehavingImpl();

c.cook();
waiter.serveCookedFood(c); //c may not yet be cooked leading to a
synchronization requirement, thus breaking the contract set by
CookableFood


More information about the Concurrency-interest mailing list