[kepler-dev] Threaded actors in the DE Domain

ian.brown@hsbcib.com ian.brown at hsbcib.com
Wed Sep 12 09:49:05 PDT 2007

Having had a quick peek at the RealTimeComposite, I think it is trying to
do something different (and more difficult) than what I am trying to do.
Basically, I have a source which creates discrete events based upon data
arriving on a TCP/IP port. It is similar to
ptolemy.actor.lib.net.DatagramReader except it is simpler in concept
because it is a connected TCP/IP socket and not a UDP connection.

The concept is the same though, the actor starts a thread that listens in
blocking mode to the socket. When enough data arrives so that a message can
be decoded, a new Event is generated with the following code:

// fireAtCurrentTime has the result that all events are called at model
// time zero with an incrementing microstep. Whilst this will work for most
// scenarios, it has the effect that the timed plotter just displays a
// line. For that reason, we need to figure out the correct time to fire
the event at.

DEDirector director =(DEDirector)(getDirector());
long start_time = director.getRealStartTimeMillis();
long time_now = java.lang.System.currentTimeMillis();
double model_time = (time_now - start_time) / 1000.0;

director.fireAt(CurrencyPairListener.this, new
ptolemy.actor.util.Time(director, model_time));

This means that DEDirector.fireAt() needs to be thread safe. I assume it
should be because that is how Datagram reader calls it ... and also the
Swing components such as the ArrowKeyListener will call it in the event
thread. In any case, it appears to work reliably until the model contains a
modal model in which case we get the exception originally reported.
Glancing through the code of fireAt() it would appear that there is an
attempt to make it thread safe (access to the calendar queue is


             ian.brown at hsbcib.                                             
             12/09/2007 17:25          "Edward A. Lee"                     
             Mail Size: 25865          <eal at eecs.berkeley.edu>             
                                       kepler-dev at ecoinformatics.org       
                                       Re: [kepler-dev] Threaded actors in 
                                       the DE Domain                       
                                       Investment Banking Europe - IBEU    

Edward, the code for the actor was at the bottom of the original mail - I
have chopped out the exception report and left it at the bottom of this
mail so it should be easier to see.

The actor is based on the Datagram Reader actor - but it reads from a
connected TCP/IP socket rather than from a UDP port.
There is only 1 DEDirector in the model and 2 of my source actors. This
means that the DEDirector.fireAt() method will be called from more than one
thread (in the same manner as the Datagram reader). Given that events will
arrive asynchronously, this would appear the only way to do it. I could
synchronise the calls to fireAt() but I would need to know what to
synchronise it against...

I'll take a look at the RealTimeComposte now...



HSBC Bank plc may be solicited in the course of its placement efforts for a
new issue, by investment clients of the firm for whom the Bank as a firm
already provides other services. It may equally decide to allocate to its
own proprietary book or with an associate of HSBC Group. This represents a
potential conflict of interest. HSBC Bank plc has internal arrangements
designed to ensure that the firm would give unbiased and full advice to the
corporate finance client about the valuation and pricing of the offering as
well as internal systems, controls and procedures to identify and manage
conflicts of interest.

HSBC Bank plc
Registered Office: 8 Canada Square, London E14 5HQ, United Kingdom
Registered in England - Number 14259
Authorised and regulated by the Financial Services Authority.


This transmission has been issued by a member of the HSBC Group
"HSBC" for the information of the addressee only and should not be
reproduced and/or distributed to any other person. Each page
attached hereto must be read in conjunction with any disclaimer
which forms part of it. Unless otherwise stated, this transmission
is neither an offer nor the solicitation of an offer to sell or
purchase any investment. Its contents are based on information
obtained from sources believed to be reliable but HSBC makes no
representation and accepts no responsibility or liability as to its
completeness or accuracy.

More information about the Kepler-dev mailing list