[cpp-threads] pthreads cancellation

Boehm, Hans hans.boehm at hp.com
Wed Apr 27 20:13:38 BST 2005


This brings up an excellent point:

Are we trying to address (hard) real-time issues with the threads API?

My personal feeling is that real-time programming is really a
completely different beast, and that pthreads has suffered a bit
by trying to do two things at once.

In my view, RTSJ != Java.

As far as C++ is concerned, I think in the discussion you referenced,
Fergus Henderson makes exactly the point I was trying to make.

Hans 

> -----Original Message-----
> From: 
> Cpp-threads_decadentplace.org.uk-bounces at decadentplace.org.uk 
> [mailto:Cpp-threads_decadentplace.org.uk-bounces at decadentplace
> .org.uk] On Behalf Of Alexander Terekhov
> Sent: Wednesday, April 27, 2005 5:04 AM
> To: cpp-threads at decadentplace.org.uk
> Subject: Re: [cpp-threads] pthreads cancellation
> 
> 
> On 4/26/05, Boehm, Hans <hans.boehm at hp.com> wrote:
> [...]
> > Java got rid of anything resembling asynchronous cancellation
> 
> Really?
> 
> http://www.rtj.org/rtsj-V1.0.pdf
> 
> "The interrupt() method in java.lang.Thread provides rudimentary 
>  asynchronous communication by setting a pollable/resettable flag 
>  in the target  thread, and by throwing a synchronous exception  
>  when the target thread is blocked at an invocation of wait(), 
>  sleep(), or join(). This specification extends the effect of 
>  Thread.interrupt() and adds an overloaded version in 
>  RealtimeThread, offering a more comprehensive and non-polling 
>  asynchronous execution control facility. It is based on throwing 
>  and propagating exceptions that, though asynchronous, are 
>  deferred where necessary in order to avoid data structure 
>  corruption.
> 
>  [...]
> 
>  When a method is declared with AsynchronouslyInterruptedException 
>  in its throws clause the platform is expected to asynchronously 
>  throw this exception if RealtimeThread.interrupt() is called while 
>  the method is executing, or if such an interrupt is pending any 
>  time control returns to the method. The interrupt is not thrown 
>  while any methods it invokes are executing, unless they are, in 
>  turn, declared to throw the exception. This is intended to allow 
>  long-running computations to be terminated without the overhead 
>  or latency of polling with java.lang.Thread.interrupted()"
> 
> Please visit also
> 
> http://www.codesourcery.com/archives/c++-pthreads/msg00124.html
> http://www.codesourcery.com/archives/c++-pthreads/msg00144.html
> 
> regards,
> alexander.
> 
> -- 
> cpp-threads mailing list
> cpp-threads at decadentplace.org.uk 
> http://decadentplace.org.uk/mailman/listinfo/cpp-threads_decad
entplace.org.uk




More information about the cpp-threads mailing list