[kepler-dev] Threaded actors in the DE Domain
Edward A. Lee
eal at eecs.berkeley.edu
Wed Sep 12 16:59:17 PDT 2007
More on this:
It actually would not be enough for the fireAt() method to be
thread safe. In fact, it can never be enough for the fireAt()
method to be thread safe.
The problem is that fireAt() takes a Time argument. You have
no assurance that between the time you calculate the value of
that Time argument and the time you call fireAt() that current
time in the DE director hasn't moved past that time.
Thus, calling fireAt() from a separate thread _always_ leaves
open the possibility of an exception that the time argument is
in the past.
You could use fireAtCurrentTime(), which we created exactly
for this purpose. But that doesn't seem to have the semantics
you want. So I suggest following my suggestion from the
previous message...
Edward
At 09:49 AM 9/12/2007, ian.brown at hsbcib.com wrote:
>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
>vertical
>// 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
>synchronised).
>
>Ian
>
>
>
>
>
> ian.brown at hsbcib.
> com
> To
> 12/09/2007 17:25 "Edward A. Lee"
> Mail Size: 25865 <eal at eecs.berkeley.edu>
> cc
> kepler-dev at ecoinformatics.org
> Subject
> Re: [kepler-dev] Threaded actors in
> the DE Domain
> Entity
> 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...
>
>Thanks,
>
>Ian
>
>
>
>************************************************************
>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.
>************************************************************
>
>-----------------------------------------
>SAVE PAPER - THINK BEFORE YOU PRINT!
>
>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.
>_______________________________________________
>Kepler-dev mailing list
>Kepler-dev at ecoinformatics.org
>http://mercury.nceas.ucsb.edu/ecoinformatics/mailman/listinfo/kepler-dev
------------
Edward A. Lee
Chair of EECS and Robert S. Pepper Distinguished Professor
231 Cory Hall, UC Berkeley, Berkeley, CA 94720-1770
phone: 510-642-0253, fax: 510-642-2845
eal at eecs.Berkeley.EDU, http://ptolemy.eecs.berkeley.edu/~eal
More information about the Kepler-dev
mailing list