Shop OBEX P1 Docs P2 Docs Learn Events
Sharing Variables Between Cogs — Parallax Forums

Sharing Variables Between Cogs

JoeFLJoeFL Posts: 10
edited 2012-12-13 12:45 in Propeller 1
Hi, If I'm using the spin debugger without any assembly code do I have to be concerned reading/writing shared variables between cogs?
For instance, will the Prop have issues while one cog is reading a variable 'at the same time' another cog is writing to that same variable?

Comments

  • Mike GreenMike Green Posts: 23,101
    edited 2012-12-13 12:05
    Sure. Spin programs can share variables between cogs. It's really easy since all variables are in the same (hub) memory. It's actually harder to share variables using assembly since each cog has its own memory. One cog cannot access another cog's memory and special instructions (RDxxxx and WRxxxx) have to be used to copy data from and to hub memory.
  • HarpritHarprit Posts: 539
    edited 2012-12-13 12:07
    Yes and Yes.
    You can see what is going on by displaying the variable on the PST. It will be all over.
    In general only one Cog should manipulate a variable. Other can use it if the variable is relatively stable meaning that it does not vary all over the place over time.

    Harprit.
  • YanomaniYanomani Posts: 1,524
    edited 2012-12-13 12:08
    JoeFL wrote: »
    Hi, If I'm using the spin debugger without any assembly code do I have to be concerned reading/writing shared variables between cogs?
    For instance, will the Prop have issues while one cog is reading a variable 'at the same time' another cog is writing to that same variable?

    Hi JoeFL

    In the Propeller there is no "at the same time" access to Hub memory, independently of the number of Cogs running programs at the same time, even when all the eight Cogs share the same Hub address to hold some contents. All eight Cogs share Hub ram in a round robin scheme, i.e. one just after the other, in case two or more of them are attempting to do an access at the same Hub address, either for reading or writing. Is up to you (the programmer) to manage any significance conflicts that could arise when more then one Cog uses the same Hub address to share some data.

    hope it helps

    Yanomani
  • YanomaniYanomani Posts: 1,524
    edited 2012-12-13 12:19
    Hi Mike Green and Harprit

    I'm like a lazy worm when typing in English.
    I was twice superseded by both you ;)
    Thanks a lot! I'm learning more each day.

    Yanomani
  • Mike GreenMike Green Posts: 23,101
    edited 2012-12-13 12:30
    There are rules for sharing variables among parallel processors (like the Propeller's cogs). For example, if only one cog can change a variable ... ever, then any number of cogs can look at the variable's value. If two cogs can change a variable ... at any time, then there has to be a lock to prevent both cogs from changing the variable at the same time. The LOCKxxx instructions do this properly.

    Look at how routines like FullDuplexSerial handle their buffers and buffer pointers. One cog is running the assembly I/O driver while another cog is running the Spin interpreter for the code calling the transmit and receive routines. These two cogs use a scheme similar to that described above where two processors can interact with a buffer (or pair of buffers) without requiring locks. This is a well known special case of parallel processing known as the "single producer - single consumer" problem.
  • Heater.Heater. Posts: 21,230
    edited 2012-12-13 12:45
    To clarify a bit,

    You can easily share a single variable between COGs without worrying about any data corruption. Can be BYTE, WORD or LONG. In Spin you can just read an write them like normal. In PASM use WDLONG, WRLONG etc. Although COGs can of course miss updates if they are reading slower than the writing COG is updating.

    BUT, if your "variable" is actually a collection of simple values, say an array of LONGs or a more complex structure, then you will have problems. If the whole array or structure has a meaning together you want the whole thing written out in an "atomic" operation and then read by another COG in an "atomic" operation. You don't want half the data updated and then find the other COG reads half old data and half new data. At that point you need locks or some other mechanism to avoid data corruption as Mike says.

    P.S.

    Mike,
    If two cogs can change a variable ... at any time, then there has to be a lock to prevent both cogs from changing the variable at the same time.
    This is not true. Writing a single variable, BYTE, WORD, or LONG, is an atomic operation due to the way HUB access works. Wrapping a lock around that does not change the situation. As I said readers may miss updates even if there is only one writer.
Sign In or Register to comment.