[kepler-dev] Threaded actors in the DE Domain

ian.brown@hsbcib.com ian.brown at hsbcib.com
Thu Sep 13 01:05:21 PDT 2007

      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       
                                       Re: [kepler-dev] Threaded actors in 
                                       the DE Domain                       
                                       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.

More information about the Kepler-dev mailing list