How many cogs are running?

DRMorrison

I was wondering if there was some way to determine during run time how many, or which cogs were running/active.
I couldn't find anything in the book; the SPR looked promising, but not quite.

Daniel

Cluso99

See my PropOS (link in my signature). IIRC the _VERS.SPIN module contains the code to check for what cogs are running.
Basically, you have a tiny pasm (or spin) program that just terminates. The you try and start that program in each cog. If success is returned then that cog is free.

DRMorrison

Ah, I see. How clever.
So some sort of loop to cycle through the cogs and test them, if I understand correctly.

SOrry, but I could not find the file you were refering to. _Vers.spin
Daniel

Cluso99

Yes, just cycle thru the cogs.

It's in the OSxxx.zip file and is _VER.spin here http://forums.parallax.com/showthread.php/138251-A-Propeller-OS-that-can-run-on-multiple-hardware...?p=1204709&viewfull=1#post1204709

Here's an extract...

    PrintString(string(" Cogs available: "))
    j~
    repeat i from 0 to 7
      cogs[i] := cognew(@entry,0) +1                    ' try to start cog(s)
      if cogs[i] 
        j++
    repeat i from 0 to 7
      if cogs[i]
        PrintString(1 + str.integerToDecimal(cogs[i]-1, 1)) ' print avail cog#
        PrintChar(" ")
        cogstop(cogs[i] -1)                             ' stop the cog(s)
    PrintString(string("(="))
    PrintString(1 + str.integerToDecimal(j,1))
    PrintStringCR(string(")"))
    crlf

DAT
'' Just a simple pasm program to test if a cog is available
              org       0
entry         jmp       #entry                  ' loops here until cogstop forced!

Heater.

Be aware that this kind of cog counting code is not bullet proof. If any running COGs are starting and stopping other COGs as the counting is happening then it cannot know about that. Further, a running COG could happen to start one or more other COGs immediately after the count is completed so you will get a over estimate of free COGs.

I think this is an insoluble problem in the general case.

But then it is good enough for most normal Spin applications.

Dave Hein

At least you would know the number of free cogs after exiting the first loop. It's certainly possible to design a system where cogs are starting up and stopping at random times, but in almost all systems cogs are started and stopped in a predictable manner, so the cog-counting routine is a perfectly fine way to do it.

In the "insoluble" general case you would need to maintain a table of cogs that are running, and use a lock to prevent other cogs from starting/stopping cogs and changing the table while you're checking it.

Heater.

Dave,

At least you would know the number of free cogs after exiting the first loop.

My point was that you would not know. Anything can happen in those few instructions between the loop ending and getting back to your code that uses the count.

It's certainly possible to design a system where cogs are starting up and stopping at random times...

It does not take much purposeful designing. With propgcc we have FCACHE so COGS can be started and stopped as your code runs even without you coding anything to explicitly do that.

...but in almost all systems cogs are started and stopped in a predictable manner,

True. Which prompts the question, if the code is so predictable why do you need a run time counting mechanism. Just grep through the code and see what it uses.

Yes, I think a common COG management system with locks would need to be in place to make this fool proof.

DRMorrison

I came up with something, but it requires that you use coginit. So this would be okay only if you are planning on starting, or keeping track of the cogs by number. Probably not good for a
large and complex program, but might be okay for a small one that only uses a couple of cogs at most.
You could then check sogStatus to find out how many, and which cogs were running.

CON

 cog1 = 0000_0001
 cog2 = 0000_0010
.
.
 cog7 = 0100_0000


VAR

 BYTE cogStatus := 0
 ++++++++++++++++++++++++++++++++
PUB Main

   <each time you start a cog, which is predictable, do the following>
 coginit(2, someMethod, @someStack)
 cogStatus ^= cog2


=================================
PUB someMethod

 <do some stuff in the method>

 <upon exiting>
 cogStatus ^= cog2
 cogstop(2)

I'm not sure if this would work or not. Let me know.

{There seems to be a bug that prevents me from placing the percent sign and 00 in front of those CON values; it strips them off. It wouldn't even allow
them in this part of the text! I typed a percent 00 here, after the colon: , but it gets stripped.}

original text from text editor. Strange behavior.



Daniel

Dave Hein

Heater. wrote: »

It does not take much purposeful designing. With propgcc we have FCACHE so COGS can be started and stopped as your code runs even without you coding anything to explicitly do that.

FCACHE does not start a new cog. It loads a snippet of PASM code into cog RAM and executes it directly. The FCACHEed code has to explicitly jump back to the LMM interpreter when it's done.

Heater. wrote: »

True. Which prompts the question, if the code is so predictable why do you need a run time counting mechanism. Just grep through the code and see what it uses.

I think it's more for diagnostic purposes to determine if the cog count matches the expected number of active cogs.

Cluso99

daniel,
yes there are problems with the forum software and percent signs.
your code would work (concept) but you would be better to define cog 0 = 00000001
try thiss...
cog0 = 1<<0
cog1 = 1<<1
etc

DRMorrison

Cluso99,
But I know that cog0 is always running, I was just trying to come up with a way to check and see if another cog was running, and if so, which one. Or, just check to see
if a particular cog was running. As I said, this would really only work if you started specific methods into specific cogs; basically assign cogs to methods and don't allow
the run time method to arbitrarily assign cogs.
A spin app that I'm working on has a set number of cog-run methods, and it would be easy to keep track of them by assigning them to specific cogs by number.
i.e. MethodA always runs in cog1, MethodB always runs in cog2 etc.

Daniel

Heater.

Dave,

FCACHE does not start a new cog....

Very true. Sorry I was getting my neurons in a knot there.

You see propgcc can indeed use FCACHE in combination with OpenMP to start and stop COGs with out there being any explicit cogstart or whatever calls in your code:

The following will spread the body of the for loop over many COGs as and when required:

#pragma omp parallel for
    for(int n=0; n < size; ++n)
        sinTable[n] = std::sin(2 * M_PI * n / size);

I played with that quite a lot a while back. But yes, it is a bit esoteric for most Propeller uses/users.

Alexander (Sandy) Hapgood

That's why programmers make the big buck haha. Basically it comes down to managing an array of 8 variables.

If it was easy, anybody could do it.

Sandy

Cluso99

DRMorrison wrote: »

Cluso99,
But I know that cog0 is always running, I was just trying to come up with a way to check and see if another cog was running, and if so, which one. Or, just check to see
if a particular cog was running. As I said, this would really only work if you started specific methods into specific cogs; basically assign cogs to methods and don't allow
the run time method to arbitrarily assign cogs.
A spin app that I'm working on has a set number of cog-run methods, and it would be easy to keep track of them by assigning them to specific cogs by number.
i.e. MethodA always runs in cog1, MethodB always runs in cog2 etc.

Daniel

Currently you know Cog0 is running. But this may not always be the case. If you use an OS or you perform your own reboot it's possible to not end up running in Cog0.
Also, it is considered poor practice to specify which cogs load which objects. In my PropOS, I set flags up to indicate what cogs are doing what processes. Catalina does a similar thing. A few of us tried unsuccessfully to make a standard.