[kepler-dev] Threaded actors in the DE Domain

Edward A. Lee eal at eecs.berkeley.edu
Thu Sep 13 08:58:55 PDT 2007

Right, the DatagramReader should be OK because of using fireAtCurrentTime().
I like the idea of a fireAtCurrentWallTime().  That would have made my
RealTimeComposite easier to write...

I also like the idea of a more relaxed variant of fireAt().
In fact, at one point, I changed fireAt() to be more relaxed,
but I backed out the change because it masked too many bugs...
But having a separate method like fireAtAtLeast() (or some
better name...)


At 01:05 AM 9/13/2007, ian.brown at hsbcib.com wrote:
>      thankyou for spending time looking into this. I understand what you
>are saying below and the ChangeRequest() suggestion is a good one - should
>the DatagramReader be modified in a similar manner - or is that unaffected
>because it calls 'fire at current time'?
>As I mentioned before, the problem with having a model source which only
>ever fires at current time is that the model time is never updated. This
>makes any of the timed sinks such as plotters and scopes useless. It would
>be good to have a function called fireAtCurretWallTime() or something
>similar. Alternatively, a fireAt which does not mind if the time is in the
>past - in the case the time is in the past, the director would just perform
>a fire at current time.
>I think in my current model it is safe to just use the ChangeRequest. This
>is because the model time will only be incremented by servicing events
>queued by my source. If I only have one source, I know that the time in the
>events it produces will always increase and as it is the only event source
>in the model it can never be the case that due to a delay, the model time
>has moved beyond the time of the event being queued.
>Things are more tricky with 2 sources - but given that they are both
>listening on the same port but for different data then they should be okay
>too. In any case, I can synchronise them on a static within the class to
>ensure that. Of course, as I get more asynchronous sources this will no
>longer work and then I'll need a fireAtCurrentTime() method which has the
>side effect of incrementing the model time.
>             "Edward A. Lee"                                               
>             <eal at eecs.berkele                                             
>             y.edu>                                                     To 
>                                       ian.brown at hsbcib.com                
>             13/09/2007 00:59                                           cc 
>             Mail Size: 10523          kepler-dev at ecoinformatics.org       
>                                                                   Subject 
>                                       Re: [kepler-dev] Threaded actors in 
>                                       the DE Domain                       
>                                                                    Entity 
>                                       Investment Banking Europe - IBEU    
>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...
>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.
>Kepler-dev mailing list
>Kepler-dev at ecoinformatics.org

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