[kepler-dev] Can "stop" interrupt "initialize()"

[Kevin Ruland]

Hi all,

I was happily working through the issues I was having with stop and 
intialize().  The answer I ended up with was this in ititialize():

try {
 sychronized( _entityCountDown ) {
   while ( _entityCountDown.currentCount() > 0 && 
!getDirector.isStopRequested() ) {
     _entityCountDown.wait();
   }
 }
}
catch ( InterruptedException e ) {
  throw new IllegalActionException("Downloads not complete");
}

if ( getDirector().isStopRequested() ) {
  throw new IllegalActionException("Execution interrupted");
}

and:

public void stop() {
  synchronized( _entityCountDown ) {
    _entityCountDown.notifyAll();
  }
}

This seems to work fine (except it raises an exception when interrupted, 
I think I should just return here).  But I've ended up with some crazy 
deadlock situation due to locking of the Workspace.

If I follow this use case:  Open workflow with numerous long running 
downloads, press "play" button.  The execution blocks in one of these 
objects in the initialize method waiting for _entityCountDown to be 
reduced to 0.  The problem is, the call back mechanism, which is 
executing in the download thread, makes calls to this object and 
attempts to reset some ports.  It seems the action of setting the ports 
attempts to write-lock the workspace.  But I guess the initialize thread 
has already locked the workspace.

It really doesn't make any sense to reconfigure output ports in a 
running workflow and I would expect that if the download completion 
needed to change the ports (say, the user build the workflow with one 
set of ports but they didn't match those specified by the downloaded 
data...) this would result in some workflow exception.

I tried moving the blocking action into preinitialize but that also 
resulted in a dead lock.

After a little effort with the debugger, I think I found where the 
deadlock is occurring, but I don't know what the corrective action is:

Looking in CompositeActor.preinitialize(), I see that it obtains read 
access to the workspace (_workspace.getReadAccess()) prior to calling 
getDirector().preinitialize().  This read access lock conflicts with the 
desire of the other download thread to mutate the output ports of the actor.

1) Should CompositeActor release the read-lock prior to making the open 
call to the director's preinitialize()?

2) Should I rewrite these data download actors so they do not attempt to 
modify the output ports during execution?

Kevin