[cs63201] Project 1

[Mikhail Nesterenko]

> If you haven't reviewed my code yet I sent you last night scrap that
> version and review this one it uses background workers to keep the
> main form from freezing when processing, tracks more variables, has
> a progress bar, and runs much faster and more stable.
> 
> Based on the printout you gave us in class I am a little unsure as
> to what kind of output you are looking for from project 1. I have
> attached my solution in c# and I was wondering if you could take a
> look at it and let me know if that is the kind of output you are
> looking for. To run it simply extract it, open the solution file in
> visual studio 2008, and hit the play button or go to the "debug"
> menu and select "start debugging".
> 
> Thanks,
> Tristan Cuevas
> 


Recode it. Do not use multiple threads. There should be a single
procedure (simulation engine) that evaluates messages one at a time
and have the particular (simulated) process receive it (and process
it). Do not use any kind of time-based events in your engine at all.
Essentially, your engine should generate a computation in the sense
discussed in class. If you like to play with it later, you might
configure the engine to generate various computations on the basis of
the configuration parameters. 

Alternative, and even better way to code the simulation engine, is to
make it evaluate the processes (rather than messages) to see which of
them is enabled (have actions enabled). After that, the simulation
engine should pick one and have it execute the enabled action. 

How the simulation engine picks the enabled processes should be
configurable. One simple approach -- round robin. 

Communication primitives such as send, receive and even broadcast
could be part of the simulation engine library. However, the "code" as
is specified in the program assignment should be in a particular set
of routines to be replaced by other functions when the algorithm
changes.

That is, your simulation engine should pick a message (first from the
queue), figure out the receiver and invoke the receiver process
function. This would make the process execute the receive action. 

Keep the input/output programming to the minimum. Forms are okay,
command line is also acceptable. 

Thanks,
--
Mikhail