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

Dhanji R. Prasanna dhanji at gmail.com
Tue Jul 25 20:26:11 EDT 2006


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?

Java is strict evaluative so it does not make sense to talk about
method-granular promises. All methods evaluate to values, period.
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