Parallel Programming with OmniThreadLib

You may have heard about

threads

and

mutltihreading

already, but you may not exactly

know what those words actually mean. The precise definition is not important for this

story. What is important are the general ideas. If you want to read more, you should start

with the entry in Wikipedia. If you are well versed in these topics, you can freely skip ahead

A

thread

variables

together with a process when it starts a program.

Modern operating systems allow multiple threads of execution inside a process. This is

achieved by creating additional

in the code. To create a thread we can

use operating system primitives (such as CreateThread on Windows), low-level runtime library

functionality as Delphi’s TThread, or higher-level concepts such as tasks and abstractions

system allows a thread to run for some time (typically few milliseconds) and then stores

the thread’s state (registers etc) into the operating system’s internal data structures and

activates some other thread. By quickly switching between multiple threads the system

gives an illusion that it is running many threads in many programs in parallel.

Multithreading is a powerful concept, but it also brings many problems. They are all

consequence of the same fact – that threads are not

isolated

.

An operating system works hard to isolate one process from another. This prevents one

belonging to a process. This gives us extreme power and flexibility. Starting multiple

threads provides all of the threads with access to the same data. It is also a source of all

problems. If multiple threads don’t only read from the shared data but write to it, you’ll

get into trouble.

It should be obvious that one thread must not modify data while another thread is reading

from it. It is harder to enforce this in practice. We can protect access to shared data by

using locking (critical sections, spinlocks, TMonitor …) or interlocked operations, but they will

slow the program down and they can introduce new problems (deadlocks).

That is why I prefer

data copying

,

communications

and

aggregation

over data sharing.

Let’s start with a simple variable access. One thread is reading from a variable and

another is writing to it.

This looks safe. Variable b will contain either 42 or previous data stored in a. Well, that is

This code behaves “as expected” (doesn’t cause problems) if the address of a gives

remainder of 0 when divided by 4. We say that a is 4-aligned. Delphi in most cases makes

all integers 4-aligned. Sadly, in some occasions, especially when structured types – classes

and records – are nested, variables are not well-aligned.

We say that the operation is atomic if it is performed in one step. Reads and writes of 4-

aligned integers are atomic on Intel platform.

The simplest way to be sure that a value is correctly aligned is to use the TOmniAlignedInt32

record provided by the OmniThreadLibrary. It makes sure that the underlying data storage

is correctly aligned and can as such be accessed atomically.

OmniThreadLibrary also implements TOmniAlignedInt64 type which creates 8-aligned int64 data.

environment is modifying the same data from two threads. In a typical program this data

modification is hidden inside an operation that we think of as

atomic

while in reality it

isn’t.

A standard example of this problem is implemented with two threads, one incrementing

the shared value and other decrementing it.

increment (or decrement) data

One way to fix such code is to use already mentioned TOmniAlignedInt32 which implements

atomic Increment and Decrement operations.

critical section. You could, for example, use OmniThreadLibrary’s TOmniCS.

Another source of problems are shared objects. If we share an object between threads and

then execute some methods of that object in different threads we have to know exactly