Flag timing in Cogs (Simple_Multicore_Demo2)

JonTitus

Could someone explain the sequence of operations that involve the flag variable in the Propeller I program, "Simple_Multicore_Demo2.spin" referred to in Parallax Semiconductor AN011? I have attached a copy of this code.

Does the use of the flags depend on the start-up time (or delay between the start time) of the two new cogs?

I get disappointed when example code includes so few comments. Examples should help users, not to confuse them.

Thanks. Jon (KZ1G)

Seairth

Hmm... I've never looked at that code before. So, the idea is that the flag is being used as a lock mechanism to serialize calls to pst. While it might be that this happens to work in this particular case, I would not suggest using this approach in general. This really should have been demonstrated with the LOCKxxx instructions, since that's what they exist for.

Now, the answer to you above question is "yes". The reason that this works is that it takes many clock cycles for each cog to initialize (something like 512*32, not remembering the actual number). So, even after the COGNEW calls, the rest of the main cog will execute before the other cogs even start executing. But, just in case, you notice that the main code "locks" using flag to protect pst.

JonTitus

Thanks, Seairth, I appreciate your comments. Like you, I would have preferred locks rather than a flag. I'll look into the code again and figure out how to take advantage of the locks. The global variable "flag" has another problem. It could get accessed from other unrelated code.

Again, thanks. --Jon

JonnyMac

That's not a great demo, but it does illustrate an important point when multiple Spin cogs might want to access a common object (PST in this case).

Lock instructions are useful, but limited. I tend to use them when I need to communicate between Spin and PASM cogs. When using Spin cogs, I use a global variable like the demo. What I don't like about the demo is that it's using a long flag for only two values (true and false, you can do that with a bit lock). When using a global value as a control flag for multiple cogs, you can use the value in that flag to indicate which cog should have access to a shared resource.

When I do this I tend to pass an id value to the cog when I launch it -- like this:

pri background_cog(id)

  repeat
    repeat until (activecog == id)
    ' cog code

    ' release flag for another cog when this process is done
    activecog := 0

In this case the flag value is activecog. The top of the cog loop waits for its turn, runs its code, then releases the flag so that another cog can run. You might have supervisor cog manage which cog gets access to the shared resource next, or you could have the cogs change the flag value to the next cog, in effect, passing a baton.

JonTitus

Thanks, Jon. I just uploaded a well-commented lock-bit demo to the OBEX so people can better understand how to use a lock bit to protect a "resource." The demo uses two cogs that share the serial communications with a PC via the USB connection. The Parallax Terminal displays information about the processes running in the cogs. I hope people find this code helpful. Look for "Lock-Bit Demo" in the OBEX. I wrote the code in SPIN. Cheers. --Jon