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

Peter Veentjer alarmnummer at gmail.com
Wed Jul 26 00:54:20 EDT 2006


On 7/26/06, Dhanji R. Prasanna <dhanji at gmail.com> wrote:
> I dont think I understand the question properly--the interface
> specifies whether or not the method is asynchronous in its contract,
> this is quite clear in documentation. Users of the interface know
> this--whether they are wrappers or "end" users. If the wrapper exposes
> the same interface to an end user but changes the semantics of the
> method (i.e. from a- to synchronous) then the wrapper has broken the
> contract. Otherwise the wrapper can simply expose a different
> interface with the correct (a- or sync) contract.
>
> What is the problem?
The problem is that the synchrone/asynchrone behaviour of the method
isn't described in the interface. If it isn't described in the
interface I assume it is synchrone. And the original implementation
even is synchrone... but the wrapper makes it a asynchrone call. So
the caller expects a call to be synchrone but finds out it is
asynchrone instead,

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 :)

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

>
> 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.

> Asynchronicity is an abstraction above the language layer and
> therefore should be specified in the contract.
>
> Plz let me know if Im missing something here-this sounds like
> something fundamental to me!!
>
> Dhanji.
>
> On 7/25/06, Peter Veentjer <alarmnummer at gmail.com> wrote:
> > > I'm opposed to this kind of transparency - I don't think it can be done.
> > I agree it is a bad thing (nice to see I'm not crazy ). But it isn't
> > difficult to make a asynchronuos wrapper. And this is the problem:
> > because you can't see if you are dealing with a synchronous or
> > asynchronous method call, it makes the design a lot more complex. The
> > difficulty is that most developers don't see this increased complexity
> > and only see the easy of making a call asynchronous with a
> > asynchronous wrapper.
> >
> > So my personal experience is that it is difficult to convince other developers.
> >
> > > So my answer is: don't do this. It isn't an implementation detail it is part
> > > of the specification of the API - after this method returns what do I know
> > > about what should have happend to the object.
> >
> > *nods his head*
> >
> > > Now there are languages that allow things to happen asynchronously but they
> > > also synchronize again when needed ie "wait by necessity".
> > >
> > > Cheers,
> > > David Holmes
> > >
> > > > -----Original Message-----
> > > > From: concurrency-interest-bounces at cs.oswego.edu
> > > > [mailto:concurrency-interest-bounces at cs.oswego.edu]On Behalf Of Peter
> > > > Veentjer
> > > > Sent: Tuesday, 25 July 2006 7:53 PM
> > > > To: concurrency-interest at cs.oswego.edu
> > > > Subject: [concurrency-interest] is choice beteen asynchrone/synchrone
> > > > methodan implementation detail?
> > > >
> > > >
> > > > I have a question about synchrone and asynchrone methods being an
> > > > implementation detail.
> > > >
> > > > If you have an interface:
> > > >
> > > > interface WaterCooker{
> > > >    void cook();
> > > > }
> > > >
> > > > You could create different implementations. It is easy to make it a
> > > > synchronous call (the default approach) but it is also quite easy to
> > > > make it asynchrone (if the call has no return value). So it is
> > > > possible to let the implementation determine what kind of call you
> > > > get: synchrone or asynchrone.
> > > >
> > > > Personally I'm not too happy with this 'transparancy'. I think it is
> > > > better that this behaviour is part of your interface definition. Why?
> > > > -of you don't know if  a call is asynchrone, some condition don't have
> > > > to success when you go to the next statement. In case of the
> > > > WaterCooker:
> > > >
> > > > WaterCooker cooker = new WaterCooker();
> > > > Cup cup = new Cup();
> > > > cooker.cook();
> > > > cooker.fill(cup);
> > > >
> > > > if you don't know the cook call is asynchrone, it could be you get
> > > > cold water in your cup.
> > > >
> > > > -you don't know if you need to worry about concurrency control issues.
> > > > If some data is shared between the two threads, you system could be
> > > > subject to data corruption and other nasty stuff. This is something
> > > > you have to be aware of, and this means that it is part of the
> > > > definition of your interface (and not an implementation detail).
> > > >
> > > > And there are other issues (bigger chance of deadlocks for example).
> > > >
> > > > The reason why I'm asking this:
> > > > with modern frameworks like Spring it is very easy to 'enhance'
> > > > objects. You could wrap a synchronous call within a asynchronous
> > > > wrapper and inject the wrapper in every components that requires it.
> > > > The component itself is not aware that the call is asynchronone. So it
> > > > is very easy to make the choice between synchronous and asynchronous
> > > > evaluation just an implementation/configuration detail.
> > > >
> > > > What are your thought about  the synchronous/asynchronous behaviour of
> > > > methods totally transparent?
> > > > _______________________________________________
> > > > Concurrency-interest mailing list
> > > > Concurrency-interest at altair.cs.oswego.edu
> > > > http://altair.cs.oswego.edu/mailman/listinfo/concurrency-interest
> > >
> > >
> > _______________________________________________
> > Concurrency-interest mailing list
> > Concurrency-interest at altair.cs.oswego.edu
> > http://altair.cs.oswego.edu/mailman/listinfo/concurrency-interest
> >
>


More information about the Concurrency-interest mailing list