I understand and fully agree that this tampers with the actor semantics. You don't want that because that would make the actor domain specific.
The director I use is my own implementation inherited from the SDFDirector. Threading in my example is controlled at two parts: 1) The model execution is managed by the subsystem which calls the ptkernel manager iterate(). 2) Setpoint dispatching is managed by solving execution constraints on certain actors. These constraints are specified modeldesign time and are solved at run-time by inserting proper hw. buffer synchronization as aspects. This way I can first test the model in Vergil, without using hw, and later deploy the model on my real execution platform. Furthermore I have other specific directors which mix this behavior more in a PN way. This is where servos are first positioned to their initial position concurrently (at the first model iteration). Here aspects are changed during execution, solving constraints differently. I need some sort of decision control logic in my models like BoolenSelector. I'm not yet familiar with the BooleanMultiplexor, but I will look at it. Thanks. Richard van der Laan, Luminis Mobile: +31 (0)65 105 22 57 Office: +31 (0)26 365 34 70 Email : [EMAIL PROTECTED] TheWeb: http://www.luminis.nl LOSS : https://opensource.luminis.net -----Original Message----- From: "Edward A. Lee" <[EMAIL PROTECTED]> Sent: Fri, November 10, 2006 11:05 am To: [EMAIL PROTECTED] Cc: ptolemy-hackers@bennett.EECS.Berkeley.EDU Subject: Re: Memory problem while firing BooleanSelect actor Unfortunately, this changes the semantics of the actor... Worse, it makes the actor nondeterministic in some domains, like PN, since now the results of your execution will depend on scheduling of threads. Perhaps you really want to use the BooleanMultiplexor actor? I suspect that you are using the SDF director... BooleanSelect is not an SDF actor, and hence should not be used with the SDFDirector. If you use it with the PNDirector, for example, then you will not get buffer overflows... We have considered throwing an exception is you use BooleanSelect with SDFDirector, but hesitated because there are actually circumstances where it can be used effectively. This requires some skill, however. We internally refer to it as the "sneaky SDF trick" :-) Edward At 07:12 AM 11/10/2006, Richard van der Laan wrote: >Hello, > >I want to share a problem I ran into while executing a model containing an >instance of the BooleanSelect actor. > >In my scenario I embedded the Ptolemy kernel as a precalculation engine to >render motion setpoints >for servomotors. Here the setpoints are eventually buffered in actors which >abstract the servos. >The model execution thread is temporary paused when the buffers are full and >is continued after hitting a certain >buffer threshold. Meanwhile in a different thread, batches of these buffered >setpoints are dispatched >to the servos. The execution of this process can last for hours. > >I discovered that only when my model contains a BooleanSelect actor the vm >will eventually run out of memory. >After some profiling I traced the problem down to one of the receiver queues >of the BooleanSelect actor. >The PTII6 beta code shows that depending on the control state, either tokens >of trueInput or falseInput will be used: > > public void fire() throws IllegalActionException { > super.fire(); > if (_control) { > // Redo this check in case the control has changed since prefire(). > if (trueInput.hasToken(0)) { > output.send(0, trueInput.get(0)); > } > } else { > if (falseInput.hasToken(0)) { > output.send(0, falseInput.get(0)); > } > } > } > >When the control state of the actor is true for all model iterations, only the >tokens of trueInput are removed >from the underlying receiver queue. This means that all falseInput tokens >remain in the other receiver queue, which >will eventually lead to an out of memory. I fixed this problem by removing >tokens from both the true and false inputs. >Depending on the control state, either the true or false tokens are send to >the output: > > public void fire() throws IllegalActionException { > final boolean trueInputHasToken = trueInput.hasToken(0); > final boolean falseInputHasToken = falseInput.hasToken(0); > Token trueInputToken = null; > Token falseInputToken = null; > > if (trueInputHasToken) { > trueInputToken = trueInput.get(0); > } > > if (falseInputHasToken) { > falseInputToken = falseInput.get(0); > } > > if (_control) { > // Redo this check in case the control has changed since prefire(). > if (trueInputHasToken) { > output.send(0, trueInputToken); > } > } else { > if (falseInputHasToken) { > output.send(0, falseInputToken); > } > } > } > >I'm not sure if I discovered a bug in the original implementation, but >nevertheless I like to share this with you all. > >Kind regards, > >Richard van der Laan, Luminis >Mobile: +31 (0)65 105 22 57 >Office: +31 (0)26 365 34 70 >Email : [EMAIL PROTECTED] >TheWeb: http://www.luminis.nl >LOSS : https://opensource.luminis.net > > >---------------------------------------------------------------------------- >Posted to the ptolemy-hackers mailing list. Please send administrative >mail for this list to: [EMAIL PROTECTED] ------------ 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 [EMAIL PROTECTED], http://ptolemy.eecs.berkeley.edu/~eal ---------------------------------------------------------------------------- Posted to the ptolemy-hackers mailing list. Please send administrative mail for this list to: [EMAIL PROTECTED]
