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

David Walend david at walend.net
Tue Jul 25 08:33:13 EDT 2006

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

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()
cooker.waitUntilDone(); //have to wait for done before filling the cup

Hope that helps,


David Walend
david at walend.net

More information about the Concurrency-interest mailing list