[concurrency-interest] is choice between asynchrone/synchrone method an implementation detail?

Peter Veentjer alarmnummer at gmail.com
Tue Jul 25 08:59:11 EDT 2006


On 7/25/06, David Walend <david at walend.net> wrote:
> On Jul 25, 2006, at 7:28 AM, concurrency-interest-
> request at cs.oswego.edu wrote:
>
> > From: "Peter Veentjer" <alarmnummer at gmail.com>
> >
> >> 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.
>
> Really? The developers I work with would prefer to live and die by
> the stack, and have to be dragged into any kind of asynchronous
> approach.

Don't get me wrong. Asynchronous calls are great. But it should be part
of the interface definition: you say that the cook method blocks
untill the water boils (synchronous) or you say: press the cook
button, but don't wait (the asynchronous call).

You can't add this behaviour transparent without creating difficult to
understand code and that is what I'm trying to discuss.

We know if we blow it, we'll spend hours or weeks trying to
> bracket the problem, so we keep things obvious and segregated.
> Enforced reading of the high-level design and quick note in the
> JavaDoc seems to be enough to alert new team members: "Here there be
> dragons."
>
> We use a services-and-messages idiom, which seems to make the
> concurrency issues very clear. On other projects I've used Runnables
> and worker threads. You'll almost always know where you stand with
> these two styles.
>
> David Holmes is right -- asynchronous side effects are part of the API.

Ok :) So we agree: asynchronous/synchronous calling of methods is not
a configuration/implementation detail but is part of the interface.

> Dave
>
> David Walend
> david at walend.net
>
>
> _______________________________________________
> 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