Re: is choice between asynchrone/synchrone method an implementation detail?

classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

Re: is choice between asynchrone/synchrone method an implementation detail?

David Walend
On Jul 25, 2006, at 7:28 AM, concurrency-interest-
[hidden email] wrote:

> From: "Peter Veentjer" <[hidden email]>
>
>> 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. 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.

>>>
>>> WaterCooker cooker = new WaterCooker();
>>> Cup cup = new Cup();
>>> cooker.cook();
>>> cooker.fill(cup);

An asynchronous style would look more like

cooker.startCooking();  //not just cook()
you.readNewspaper();
cooker.waitUntilDone(); //have to wait for done before filling the cup
cooker.fill(cup);

Hope that helps,

Dave

David Walend
[hidden email]


_______________________________________________
Concurrency-interest mailing list
[hidden email]
http://altair.cs.oswego.edu/mailman/listinfo/concurrency-interest
Reply | Threaded
Open this post in threaded view
|

Re: is choice between asynchrone/synchrone method an implementation detail?

alarmnummer
On 7/25/06, David Walend <[hidden email]> wrote:

> On Jul 25, 2006, at 7:28 AM, concurrency-interest-
> [hidden email] wrote:
>
> > From: "Peter Veentjer" <[hidden email]>
> >
> >> 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
> [hidden email]
>
>
> _______________________________________________
> Concurrency-interest mailing list
> [hidden email]
> http://altair.cs.oswego.edu/mailman/listinfo/concurrency-interest
>
_______________________________________________
Concurrency-interest mailing list
[hidden email]
http://altair.cs.oswego.edu/mailman/listinfo/concurrency-interest
Reply | Threaded
Open this post in threaded view
|

Re: is choice between asynchrone/synchrone method an implementation detail?

Brian Goetz
> 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).

And blocking methods (those that wait for an action to occur in another
thread) should strongly consider throwing InterruptedException, both to
facilitate cancellation, and as a nice way of saying "I'm a blocking
method."
_______________________________________________
Concurrency-interest mailing list
[hidden email]
http://altair.cs.oswego.edu/mailman/listinfo/concurrency-interest