is choice beteen asynchrone/synchrone method an implementation detail?

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

is choice beteen asynchrone/synchrone method an implementation detail?

alarmnummer
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
[hidden email]
http://altair.cs.oswego.edu/mailman/listinfo/concurrency-interest
Reply | Threaded
Open this post in threaded view
|

Re: is choice beteen asynchrone/synchrone methodan implementation detail?

David Holmes-3
Peter,

I'm opposed to this kind of transparency - I don't think it can be done. The
programming model is either synchronous or asynchronous you can't
arbitrarily switch between them unless you always assume asynchronous. But
then whenever you have an asynchronous call you ultimately need some kind of
synchronous method to "rendezvous" with the object again.

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.

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: [hidden email]
> [mailto:[hidden email]]On Behalf Of Peter
> Veentjer
> Sent: Tuesday, 25 July 2006 7:53 PM
> To: [hidden email]
> 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
> [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 beteen asynchrone/synchrone methodan implementation detail?

alarmnummer
> 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: [hidden email]
> > [mailto:[hidden email]]On Behalf Of Peter
> > Veentjer
> > Sent: Tuesday, 25 July 2006 7:53 PM
> > To: [hidden email]
> > 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
> > [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 beteen asynchrone/synchrone methodan implementation detail?

Dhanji R. Prasanna
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 <[hidden email]> 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: [hidden email]
> > > [mailto:[hidden email]]On Behalf Of Peter
> > > Veentjer
> > > Sent: Tuesday, 25 July 2006 7:53 PM
> > > To: [hidden email]
> > > 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
> > > [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
>
_______________________________________________
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 beteen asynchrone/synchrone methodan implementation detail?

alarmnummer
On 7/26/06, Dhanji R. Prasanna <[hidden email]> wrote:

> 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?
The problem is that the synchrone/asynchrone behaviour of the method
isn't described in the interface. If it isn't described in the
interface I assume it is synchrone. And the original implementation
even is synchrone... but the wrapper makes it a asynchrone call. So
the caller expects a call to be synchrone but finds out it is
asynchrone instead,

The point I'm trying to make is that the choice of
synchrone/asynchrone is not an implementation/configuration detail,
but part of the definition of the function. And if I understand you
correctly, you agree :)

How you are going to implement the asynchrone call (after you know the
call is asynchrone) is just a configuration/implementation detail.

>
> Java is strict evaluative so it does not make sense to talk about
> method-granular promises. All methods evaluate to values, period.
Not void methods. These are the functions you 'could' make asynchrone
without anyone knowing.

> 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 <[hidden email]> 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: [hidden email]
> > > > [mailto:[hidden email]]On Behalf Of Peter
> > > > Veentjer
> > > > Sent: Tuesday, 25 July 2006 7:53 PM
> > > > To: [hidden email]
> > > > 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
> > > > [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
> >
>
_______________________________________________
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 beteen asynchrone/synchrone methodan implementation detail?

Dhanji R. Prasanna
On 7/26/06, Peter Veentjer <[hidden email]> wrote:
> The point I'm trying to make is that the choice of
> synchrone/asynchrone is not an implementation/configuration detail,
> but part of the definition of the function. And if I understand you
> correctly, you agree :)

Yes, I suppose I do. =)

>
> How you are going to implement the asynchrone call (after you know the
> call is asynchrone) is just a configuration/implementation detail.
>

Afai concerned it is poor documentation that does not make clear what
the method is expected do. ;)

> >
> > Java is strict evaluative so it does not make sense to talk about
> > method-granular promises. All methods evaluate to values, period.
> Not void methods. These are the functions you 'could' make asynchrone
> without anyone knowing.
>

I disagree, because making them asynchronous if the contract reports
otherwise is fallacious and may break lexical guarantees. To take your
own example:

public interface CookableFood {
/**
  * When this method returns food is cooked
  */
  public void cook();
}

//usage scenario:
CookableFood c = CookerFactory.getMisbehavingImpl();

c.cook();
waiter.serveCookedFood(c); //c may not yet be cooked leading to a
synchronization requirement, thus breaking the contract set by
CookableFood
_______________________________________________
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 beteen asynchrone/synchrone methodan implementation detail?

alarmnummer
> I disagree, because making them asynchronous if the contract reports
> otherwise is fallacious and may break lexical guarantees. To take your
> own example:
That is why the could is between quotes... you could... it doesn't
mean you should :)

>
> public interface CookableFood {
> /**
>   * When this method returns food is cooked
>   */
>   public void cook();
> }
>
> //usage scenario:
> CookableFood c = CookerFactory.getMisbehavingImpl();
>
> c.cook();
> waiter.serveCookedFood(c); //c may not yet be cooked leading to a
> synchronization requirement, thus breaking the contract set by
> CookableFood
>
_______________________________________________
Concurrency-interest mailing list
[hidden email]
http://altair.cs.oswego.edu/mailman/listinfo/concurrency-interest
Reply | Threaded
Open this post in threaded view
|

ExecutorCompletionService is dangerous for critical app!!

yangjs
 
hi,all
 
   I  use ExecutorCompletionService in my app ,that is a producer-consumer pattern. code like follow:
 
  blic ExecutorCompletionService jobQueue = new ExecutorCompletionService<Document>(
   getThreadExecutor(), getBlockingQueue(100));
 
I found when ExecutorCompletionService found queue full,then the finished job was discarded.
after read the implement code ,the ExecutorCompletionService implments the QueueingFuture as follow:
 
    private class QueueingFuture extends FutureTask<V> {
        QueueingFuture(Callable<V> c) { super(c); }
        QueueingFuture(Runnable t, V r) { super(t, r); }
        protected void done() { completionQueue.add(this); }
    }
 
   when queue  full, completionQueue.add(this) will throw exception but swallowed by Future self.so the task will disappear,this is very dangerous for my critical app.
 
 why use completionQueue.add(this) ,why not use completionQueue.put(this),this is a block method , we want use throttling strategy when queue is full,I will implement self ,like this :
 
 
    private class QueueingFuture extends FutureTask<V> {
        QueueingFuture(Callable<V> c) { super(c); }
        QueueingFuture(Runnable t, V r) { super(t, r); }
        protected void done() { completionQueue.put(this); }
    }
 
 
is right?

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

why thread implement transform thread name to char[]?

yangjs
 
  When I read Thread implement code, I found when set thread name , name is String type ,the thread implement code will transform String to char[],when getName(), then transform to String!
  who can explain ?why?
 
thx
 
Best regards,
 

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

Re: why thread implement transform thread nameto char[]?

David Holmes-3
That would be to make it easier to access the thread name from within C code in the VM. Just a guess. :) I don't think this is really an issue today but this code has been around a long time.
 
Cheers,
David Holmes
-----Original Message-----
From: [hidden email] [mailto:[hidden email]]On Behalf Of yangjs
Sent: Tuesday, 15 August 2006 4:05 PM
To: [hidden email]
Subject: [concurrency-interest] why thread implement transform thread nameto char[]?

 
  When I read Thread implement code, I found when set thread name , name is String type ,the thread implement code will transform String to char[],when getName(), then transform to String!
  who can explain ?why?
 
thx
 
Best regards,
 

_______________________________________________
Concurrency-interest mailing list
[hidden email]
http://altair.cs.oswego.edu/mailman/listinfo/concurrency-interest