MASON-INTEREST-L Archives

August 2007

MASON-INTEREST-L@LISTSERV.GMU.EDU

Options: Use Monospaced Font
Show Text Part by Default
Condense Mail Headers

Message: [<< First] [< Prev] [Next >] [Last >>]
Topic: [<< First] [< Prev] [Next >] [Last >>]
Author: [<< First] [< Prev] [Next >] [Last >>]

Print Reply
Content-type:
multipart/mixed; boundary=Apple-Mail-9-410881641
Sender:
MASON Multiagent Simulation Toolkit <[log in to unmask]>
Subject:
From:
Sean Luke <[log in to unmask]>
Date:
Mon, 13 Aug 2007 12:53:15 -0400
MIME-version:
1.0 (Apple Message framework v752.3)
Comments:
To: MASON Multiagent Simulation Toolkit <[log in to unmask]>
Reply-To:
MASON Multiagent Simulation Toolkit <[log in to unmask]>
Parts/Attachments:
text/plain (1444 bytes) , Schedule.java (26 kB) , text/plain (26 kB)
Here's a further revised Schedule for anyone interested.  Totally  
experimental -- indeed, basically untested.  It's been modified in  
the following way.

	- Any thread can now schedule things on the schedule at any time,  
even while schedule.step() is running.
	- Any thread can now call reset() or simstate.kill(), but be advised  
that other threads could theoretically add new things on the schedule  
even after it's been reset, thus nullifying the point of reset() or  
kill().
	- Any thread can call time() (or a new identical method, getTime())  
or getSteps()
	- schedule.step() explicitly looks for reentrancy and denies it
	- I've deleted the numOrders constructor.  It's time.
	- I've deleted the throwsExceptions option.  A bit faster and  
cleaner.  It's time.

I do this by employing two locks: (1) the Schedule itself, whose  
synchronization controls access to step() to prevent some race  
conditions, and (2) an internal lock which controls access to the  
time, steps, shuffling parameter, and heap.  Using this second lock  
allows some finer control over critical regions and thus makes  
possible the "any thread" stuff in the bullets above.

It doesn't look much slower, so I may keep it.  But I won't add it to  
CVS without some major testing. Anyone up for it?

To be threadsafe, AsynchronousSteppables and ParallelSequence still  
shouldn't call reset() or simstate.kill(), but rather should schedule  
a Steppable which calls simstate.kill().




Sean

ATOM RSS1 RSS2