View this PageEdit this PageAttachments to this PageHistory of this PageHomeRecent ChangesSearch the SwikiHelp Guide
Hotspots: Admin Pages | Turn-in Site |
Current Links: Case Final Project Summer 2007

The Multi-threaded OTIB OS Simulation

Description

Multiple Threads, the holy grail of single threaded applications.

The Simulation

Our Simulation consisted of a "Kernel" composed of two sleeping processes and a Message Queue. While the design originally had a Scheduler built in, it became unnecessary and what were KernelMessages were just handled instantly while the lower priority GameMessages were handled at the time of their execution.

Responsiveness

Because all user messages are considered KernelMessages, they were handled instantly. GameMessages were inserted into a queue ordered by timestamp. The timestamps are set with a precision of 1 second. However, the handler for GameMessages executes every 500ms. This greatly improved the responsiveness of secondary messages by allowing near instant handling.

The threads

resume
"Resume the Game Engine process"

process := [[nil isNil] whileTrue:
[self handleNextMessage isNil ifTrue: [(Delay forMilliseconds: 500) wait. ].
].] newProcess.

simProcess := [
[nil isNil] whileTrue: [
(Delay forMilliseconds: ((600 to: 1500) atRandom)) wait.
GameEngine instance currentLocation worldObjectBag do: [:curr |
(curr model isKindOf: Person) ifTrue: [
((curr model currentAction isKindOf: DoNothing) or: [curr model currentAction isNil not or: [curr model finalMessage isNil not]]) ifTrue:
[
curr model invokeSimAction.
].
(curr model currentAction isKindOf: DoNothing) ifTrue:
[
curr model doCurrentAction.
].
].
].
].
] newProcess.

process resume.
simProcess resume.


The process thread handled the execution of GameMessages. The simProcess thread handled the actual "Simulation" of people getting bored and doing things. It was executed at random intervals allowing the simulation to move somewhat randomly.

Problems

Squeak's Context Switching and Scheduling seems to have some problems with Morphic. Under heavy load, our program would display huge visual artifacts, sometimes rendering it unplayable by not rendering. This was corrected by having the threads execute at larger intervals as well as recoding some components in Morphic (in particular, the scroll bars).

Links to this Page