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

Peter Veentjer alarmnummer at gmail.com
Tue Jul 25 07:27:57 EDT 2006


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


More information about the Concurrency-interest mailing list