Question on cog termination:

andrewsi

Let's say you have a task that you want to run in a separate cog because it's potentially lengthy (e.g. a long lock on a semaphore) and you don't want to block your main cog's execution, but you want it to terminate when it's complete and release its cog back to the pool. (Perhaps this is all faulty program design on my part, but bear with me for a moment. :smilewinkgrin:)

Will the cog be returned to the pool automatically when its method's execution ends, or will it remain "assigned" indefinitely unless something explicitly calls Cogstop on its Cog ID?

Thanks-
Andy

andrewsi

Think I've answered my own question by the Q&A page (excellent!)

Just use COGSTOP(CogID) at the end of the method, to shut itself down.

Mike Green

It's even simpler than that. When you do a COGNEW or COGINIT, the return address for the call to the method (subroutine) to be started in the new cog is forced to be to a COGSTOP. When the main method for that cog exits, the cog gets stopped automatically.

andrewsi

So that basically answers my question - the cog gets returned to the pool since there's an implicit COGSTOP if it runs out of code?

Phil Pilgrim (PhiPi)

andrewsi wrote:

... the cog gets returned to the pool since there's an implicit COGSTOP if it runs out of code?

Yes, that's true of Spin cogs, but not PASM cogs. Those require a cogstop; otherwise, they will just keep looping, rolling over from $1ff to $000. Also, if you have a Spin cog that's finished with its computations but needs to keep output pins or counters in a certain state, you can end it with a naked repeat to keep it alive.

-Phil