Processes

A process is an instance of a program being executed by a processor and is responsible for the sustained performance of activity described by that program. This includes the code, its static and dynamic data, its execution states, and the states of the processor itself.

The term process is often used interchangeably with the term task; however, for our purposes a process is a long-term phenomena whereas a task is much more short-lived.

A task is a brief activity from a small part of a process. It is the result of breaking a process into smaller pieces with intent to provide only momentary execution of each and to interleave them with other tasks from other processes.

Multi-processing is the act of executing multiple programs in parallel. This involves using multiple processors (one for each program being executed) to achieve true concurrency.

A multi-processing system can execute multiple processes concurrently without any latencies between them, except when they share a mutually-exclusive resource.

Multi-tasking is the act of executing small pieces of multiple programs in series. This involves using a single processor and rapidly switching between tasks to give the illusion of process concurrency.

A multi-tasking system can execute multiple processes, but only a piece of each at any given time, often with unpredictable latencies that worsen as more processes are involved.

Yes, it's what the Propeller was built to do well.

In typical applications, cogs perform most operations within their own Cog RAM, and with the System Counter and I/O pins. Since access to those resources is unimpeded by any cog, the Propeller often achieves extreme concurrent processing throughput.

Though it wasn't built with this in mind, a simple task-switching mechanism can be realized in Propeller Assembly through the use of the JMPRET instruction.

The Propeller can have up to eight cogs executing processes at any time. This does not limit your application to eight objects, eight Spin methods, or eight assembly routines– just eight cogs executing code at the same time. Some processes may need to perform continuously, like the main program loop, or code that is parsing a constant stream of data. Other processes may only need to occur once in a while; when they are done, the cog’s resources can be freed up for another process.

Each cog also has two counter modules that can each handle a separate high-speed repetitive process in 32 different operation modes, monitoring or controlling up to two I/O pins each. Once the counter modules are configured, the cog may continue executing code while the counter modules operate simultaneously.

So, theoretically, the Propeller chip can be running a maximum of 24 simultaneous processes; 16 counter operations and 8 sophisticated, programmatic processes.

In Propeller Assembly, it is also possible to use the JMPRET instruction to achieve simple multi-tasking in a cog. This logically adds processes to the system, though they are executed sequentially, rather than in parallel.

A memory collision occurs when two or more cogs operate on a block of memory at the same time in a way that causes conflict between them.

A cog has exclusive access to its own Cog RAM, so no memory collision between cogs can occur there. However, all cogs share Main RAM; care must be taken to avoid collisions there.

A cog can read or write a byte, word, or long from Main RAM as an atomic operation—a single operation that no other cog can interfere with. In contrast, cogs can unknowingly interfere with each other's successive atomic operations (multiple reads or writes of bytes, words, or longs from Main RAM) since their respective operations are naturally interleaved when accessing a mutually-exclusive resource.

This situation can cause problems if two or more cogs simultaneously perform multiple opposing operations on the same logical block of memory. For example, two cogs may be tasked to cooperate on data contained in a block of memory 10 bytes in length. If one cog starts writing to the 10 bytes while another is reading, timing variations in their respective program loops can easily cause the "reading" cog to read a mixture of both new byte-sized data and old byte-sized data.

To prevent such misreads or miswrites, the cogs must coordinate their efforts through an agreed-upon synchronization mechanism. This mechanism serves as a "flag" to signal when a cog is performing a non-atomic operation on a mutually-exclusive resource. All cogs involved with that resource must check and set the "flag" before proceeding, and must clear the flag to indicate when they are done.

In many situations where memory is involved, a simple solution is to designate a byte, word, or long within the memory block to serve as this synchronization flag, but since that memory-based flag can not be read and written within the same atomic operation (it requires a read operation followed by a write operation) it may not work flawlessly for all situations. For this reason, a dedicated synchronization mechanism exists, called Locks, or semaphores.

The Propeller has 8 global lock bits which can be read and written simultaneously, as a single operation. When used properly, the lock bits can facilitate synchronization between cogs for any purpose desired; not just for Main RAM usage. The lock bits are managed through four commands: LOCKNEW, LOCKSET, LOCKCLR, and LOCKRET.