[kepler-dev] Threaded actors in the DE Domain
Edward A. Lee
eal at eecs.berkeley.edu
Thu Sep 13 09:04:09 PDT 2007
Ack, the call to executeChangeRequests() defeats the thread safety!
In fact, the code is equivalent to just doing it in line.
Why is the change request deferred? What is the DE Director doing
when the change request is made? Perhaps there is a bug there that
we should fix... To find out, I would try setting a breakpoint
on the requestChange() line, and look at the state of the other
(main) thread when this request is made. I don't understand why
the request would be ignored...
Edward
At 02:54 AM 9/13/2007, ian.brown at hsbcib.com wrote:
>The code that I now have, and which works is as follows:
>
>if (processInput(sb.toString(), instrument)){
> // 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.
> //getDirector().fireAtCurrentTime(CurrencyPairListener.this);
> //
> ptolemy.kernel.util.ChangeRequest request = new
>ptolemy.kernel.util.ChangeRequest(CurrencyPairListener.this, ""){
> protected void _execute(){
> 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;
> try {
> director.fireAt(CurrencyPairListener.this, new
>ptolemy.actor.util.Time(director, model_time));
> } catch (IllegalActionException ex) {
> throw new RuntimeException("fireAtCurrentTime() "+ "threw
>an exception", ex);
> }
> }
> };
> requestChange(request);
> executeChangeRequests();
>}
>
>I had to put in the call to executeChangeRequests() because otherwise the
>change requests are deferred until the execution is stopped.
>Looking at this though, and digging into the code a bit, it would seem that
>I could get the same result by surrounding the sensitive block with a
>synchronized (_changeLock){}. That would appear to do the same thing
>without the overhead of building the changeRequests lists and it would also
>ensure that other change requests that I may want blocked do not occur.
>
>Ian
>
>
>
>
>
> "Edward A. Lee"
> <eal at eecs.berkele
> y.edu> To
> ian.brown at hsbcib.com
> 13/09/2007 00:55 cc
> Mail Size: 26054 kepler-dev at ecoinformatics.org
> Subject
> Re: [kepler-dev] Threaded actors in
> the DE Domain
> Entity
> Investment Banking Europe - IBEU
>
>
>
>
>
>
>
>
>
>
>
>I see... Yes, as you discovered, this code won't work.
>There are other problems lurking besides the exception you saw...
>
>I would suggest that your thread should call fireAt() inside the
>body of a change request. Something like:
>
> ChangeRequest request = new ChangeRequest(suitable args) {
> protected void _execute() {
> get all the time information you need
> fireAt(...);
> }
> }
> requestChange(request);
>
>The _execute() method will be evaluated by the DEDirector at a
>point where current time is stable, it's not in the middle of doing
>causality analysis (the cause for the error you saw), and no
>actor is in the middle of firing.
>
>The reason the error went away when you changed the FSM actor
>to not allow modifications is simply that you removed a very
>costly computation that the DEDirector was doing on each FSM
>transition (you reported this problem before, and it's on my
>"to do" list). However, all you did was reduce the size of
>the target for concurrency errors. You didn't eliminate the
>concurrency errors...
>
>Edward
>
>
>************************************************************
>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