[Javapathfinder-svn] SF.net SVN: javapathfinder:[1885] branches/mango/Mango

[<fra...@us...>]

Revision: 1885
          http://javapathfinder.svn.sourceforge.net/javapathfinder/?rev=1885&view=rev
Author:   frankrimlinger
Date:     2009-09-02 15:11:47 +0000 (Wed, 02 Sep 2009)

Log Message:
-----------
Happily, no fundamental modification of the ThreadSupport project is necessary to support "user" blocking of a Commander thread.  The point is that a ReentrantLock has already been established in the SystemBuilder, called "executionLock".  The command that holds the lock is the only one that gets to execute.  This lock was established to *prevent* higher priority commands from swapping in randomly while a lower priority command was running. So if a lower priority command wants to block, it does the following:

create a new Semaphore sem.
create the higher priority message, passing sem
post the higher priority message
unlock the executionLock
acquire sem
lock the executionLock


All the higher priority message has to do is release sem when it is done.  The lower priority message will then unblock and continue execution.

BUT, what happens if the lower priority message is so unlucky that it swaps out just after unlocking.  Then the higher priority message kicks in, does its thing, and attempts to release the semaphore before it was ever acquired?  Well, the higher priority thread can accommodate this situation like so:

while(true){
	if(!sem.hasQueuedThreads()){
		Thread.sleep(1);
	}
	else{
		sem.release();
		break;
	}
}

It's a piece of cake!  The InterruptCode interface declares two methods, getSemaphore() and transit().   ScheduleRequestMsg implements this interface, so extensions can now run as interrupt code.  All they have to do is accept a Semaphore and pass it to super(), and call transit() instead of transit(Command.E.FINISH)   The base class implementation of transit() handles the cleanup at FINISH time.

For any Command that needs to block, there is the incantation:

wait( new XXXmsg(<usual arguments>, new Semaphore()))

The method wait() accepts any Command implementing InterruptCode, and calls its getSemphore() method to implement the blocking logic for this command.

Modified ScheduleRequestMsg and Command to accomodate the InterruptCode interface.  Created the new lowest priority for the session threads, JPFREWRITER.  With JPFrewriter running the show, its not clear that that the "session" concept has any meaning, but we just let sessions continue to exist until it is clear they are no longer needed.

The whole idea of having a static set of threads tied to pre-defined priorities is feeling a little 20th century, but oh well, good enough for now.

Modified Paths:
--------------
    branches/mango/Mango/Mango/src/mango/control/msg/ReplayedMsg.java
    branches/mango/Mango/Mango/src/mango/worker/msg/ScheduleAutoCommand.java
    branches/mango/Mango/Mango/src/mango/worker/workFlow/model/EventLoopTrap.java
    branches/mango/Mango/Mango/src/mango/worker/workFlow/msg/ScheduleRequestMsg.java
    branches/mango/Mango/Mango/src/mango/worker/workFlow/msg/TrapCommand.java
    branches/mango/Mango/Mango/src/mango/worker/workFlow/msg/WorkerCommand.java
    branches/mango/Mango/ThreadSupport/src/threadModel/Command.java
    branches/mango/Mango/ThreadSupport/src/threadModel/Priority.java
    branches/mango/Mango/ThreadSupport/src/threadModel/SystemBuilder.java

Added Paths:
-----------
    branches/mango/Mango/ThreadSupport/src/threadModel/InterruptCode.java


This was sent by the SourceForge.net collaborative development platform, the world's largest Open Source development site.