Spin Start/Stop Methods

_eel

I've got an question:

The Propeller Manual (p119 3rd paragraph) says that if an object has methods to Start and Stop cogs, you should call the Stop method before the Start method, otherwise "a new cog would start up and overwrite another cog's workspace variables, such as Stack."·I don't understand the meaning of this statement. cognew() does not start a cog if none are available, and why would you care if you·erase something you're going to overwrite anyway? Is this a general statement, or is it specific to the example in the book (Output.spin)?

Thanks,

Stephen

Mike Green

Think about it. An object makes use of a cog. It's started using its "start" method and there's a bug in the main program so another call is made to the object's "start" method. The cog that was previously started is still running and presumably using the variables in the object's VAR section. Unless the "start" method is written to detect this case and either stop the running cog before starting a new one or return without starting a new cog, you'll get into trouble as you try to start a new cog with COGNEW using the same stack area and variables as the current cog is using. A 2nd COGNEW will start a new cog as long as there's one available.

Anyway, the conventional way to take care of this is to use the existing "stop" method to stop any currently running cog (for this object) before starting up a new one. Since COGNEW returns the number of the cog used, the "start" method saves this in the workspace and the "stop" method uses this saved value to determine whether there's already a cog running and uses this to stop it. Often the "start" method already has a call to the "stop" method built into it.

kuroneko

Imagine you have a piece of code which just executes cognew in the start method. Furthermore, the code executed subsequently accesses HUB memory (e.g. status, results). Now you call the start method twice. Given available resources you may end up with two cogs now running the same code (which in itself isn't wrong) but it also accesses the same HUB locations which isn't what you want (contention).

So calling stop just makes sure that you don't get undefined results. You could argue that calling the start method more than once is broken behaviour anyway ...

HTH

Phil Pilgrim (PhiPi)

Most well-written objects that include both Start and Stop methods, will include a state variable called "Running" or somesuch to indicate whether Start has been called. If Start is called when Running is non-zero, Start will call Stop first before doing anything else. Checking this state variable is also useful in other methods within the object to prevent them from continuing if Start was never called in the first place.

-Phil