Home > Concurrent programming > Explanation of concurrent programming. Part 2: examples

Explanation of concurrent programming. Part 2: examples

In the previous part we have covered a lot of theory, so in this part we will take a look at real-world examples of concurrent environments and will try to see how well they will fit with our theory.

Classical Unix environment could be considered as “message-passing”-class system. Each task is represented by “process”. All processes have access only to their local data. OS even protects memory of the process from being physically accessed from other processes. Processes can communicate through files: one process can write into a file, and another process can read from it. There are even special kinds of files, called “pipes”, which are designed specially for inter-process communication: if there are no data in pipe then reader will block until data will arrive or pipe will be closed. Unix guarantees that writing less then certain number of bytes into a file will happen atomically. There is an easy solution for this problem: you can have two files, one for data, and another for signalling. Subsequent versions of Unix-like OSes have also another message-passing facility called “message queue”.

A “semaphore” is a good example of guarded shared memory. However, it’s capacity is limited to single integer. More than that, it interacts with scheduler, so some operations like “get” can block the process.

Another well-known concurrent framework is called “POSIX threads”. It specifies that tasks have all their data memory shared, but each task has an isolated stack. For languages like C and C++ this means that “automatic” variables, which are stored on stack, will always be thread-local, but “global” and “heap” variables will be shared. This framework could be classified as “shared memory with critical code sections”. Critical section is started then thread “grabs” an object called “mutex”, and ends then thread “releases” this mutex. While grabbed by one thread, mutex cannot be grabbed by any other threads. There are two kinds of “grab” operation: “blocking” which puts thread asleep if mutex could not be grabbed, and “non-blocking” which returns error if mutex could not be grabbed. There is also a facility called condition variable. It is useful then thread doesn’t have any work to do, and wants to go asleep, but it doesn’t know when to wake up, so it will be woken up by another thread.

Threads in Java are very much like POSIX threads. The only difference is that it is implemented not as library, but as a part of language itself.

  1. No comments yet.
  1. No trackbacks yet.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s

%d bloggers like this: