Concurrent/ parallel programming

Concurrent programming
By-
Tausun Akhtary
Software Analyst
Ipvision Canada Inc
Source : Apple Documentations and
Internet Research

Concurrent Programming
Concurrency describes the concept of running several tasks at the same time. This can either
happen in a time-shared manner on a single CPU core, or truly in parallel if multiple CPU cores are
available.
Concurrent program is a program that has different execution path that run simultaneously.
- Bishnu Pada Chanda,
IPVision Canada Inc

Parallel vs Concurrent
Concurrency means that two or
more calculations happen within the
same time frame, and there is
usually some sort of dependency
between them.
Parallelism means that two or more
calculations happen simultaneously.

Concurrency/Multitasking
Multitasking allows several activities to occur concurrently on the computer
● Levels of multitasking:
○ Process-based multitasking : Allows programs (processes) to run concurrently
○ Thread-based multitasking (multithreading) : Allows parts of the same process (threads)
to run concurrently

Merits of concurrent Programming/Multitasking
● Speed
● Availability
● Distribution

Thread
Only CSE people can understand Thread and String are not the same.
● In computer science, a thread of execution is the smallest sequence of programmed
instructions that can be managed independently by a scheduler, which is typically a part of
the operating system.
● The implementation of threads and processes differs between operating systems, but in most
cases a thread is a component of a process.
● Multiple threads can exist within one process, executing concurrently (one starting before
others finish) and share resources such as memory, while different processes do not share
these resources. In particular, the threads of a process share its instructions (executable
code) and its context (the values of its variables at any given time).

Concurrency challenges
● Shared resource
● Race condition
● Critical section

● Mutual exclusion

● Deadlock
void swap(A, B)
{
lock(lockA);
lock(lockB);
int a = A;
int b = B;
A = b;
B = a;
unlock(lockB);
unlock(lockA);
}
swap(X, Y); // thread 1
swap(Y, X); // thread 2

● Priority Inversion
● Starvation

Lock, Mutex, Semaphore
● Semaphores have a synchronized counter and mutex's are just binary (true / false).
● A semaphore is often used as a definitive mechanism for answering how many elements of a
resource are in use -- e.g., an object that represents n worker threads might use a
semaphore to count how many worker threads are available.
● Truth is you can represent a semaphore by an INT that is synchronized by a mutex.

Mutex vs Semaphore (the toilet example)
● Mutex
○ Is a key to a toilet. One person can have the key - occupy the toilet - at the time. When
finished, the person gives (frees) the key to the next person in the queue.
● Semaphore
○ Is the number of free identical toilet keys. Example, say we have four toilets with
identical locks and keys. The semaphore count - the count of keys - is set to 4 at
beginning (all four toilets are free), then the count value is decremented as people are
coming in. If all toilets are full, ie. there are no free keys left, the semaphore count is 0.
Now, when eq. one person leaves the toilet, semaphore is increased to 1 (one free key),
and given to the next person in the queue.

Concurrency in ios
Apple provides :
● Threads
● Grand Central Dispatch
● Dispatch Queue
● Dispatch source
● OPeration Queue
● Synchronization

Synchronization in ios
● Atomic operation
○ #include <libkern/OSAtomic.h>, mathematical and logical operations on 32-bit and 64-bit values
○ Does not block anything, lighter than synchronized
● Memory Barriers
○ A memory barrier is a type of nonblocking synchronization tool used to ensure that memory operations occur
in the correct order. A memory barrier acts like a fence, forcing the processor to complete any load and store
operations positioned in front of the barrier before it is allowed to perform load and store operations positioned
after the barrier.
○ Simply call the OSMemoryBarrier function
● Volatile Variables
○ Applying the volatile keyword to a variable forces the compiler to load that variable from memory each time it
is used. You might declare a variable as volatile if its value could be changed at any time by an external
source that the compiler may not be able to detect

● Locks
○ Mutex - A mutually exclusive (or mutex) lock acts as a protective barrier around a resource. A mutex is a type
of semaphore that grants access to only one thread at a time.
○ Recursive lock - A recursive lock is a variant on the mutex lock. A recursive lock allows a single thread to
acquire the lock multiple times before releasing it. Other threads remain blocked until the owner of the lock
releases the lock the same number of times it acquired it. Recursive locks are used during recursive iterations
primarily but may also be used in cases where multiple methods each need to acquire the lock separately.
○ Read-write lock - A read-write lock is also referred to as a shared-exclusive lock. This type of lock is typically
used in larger-scale operations and can significantly improve performance if the protected data structure is
read frequently and modified only occasionally. During normal operation, multiple readers can access the data
structure simultaneously. When a thread wants to write to the structure, though, it blocks until all readers
release the lock, at which point it acquires the lock and can update the structure. While a writing thread is
waiting for the lock, new reader threads block until the writing thread is finished. The system supports read-
write locks using POSIX threads only.

● Locks
○ Distributed lock - A distributed lock provides mutually exclusive access at the process level. Unlike a true
mutex, a distributed lock does not block a process or prevent it from running. It simply reports when the lock is
busy and lets the process decide how to proceed.
○ Spin lock - A spin lock polls its lock condition repeatedly until that condition becomes true. Spin locks are most
often used on multiprocessor systems where the expected wait time for a lock is small. In these situations, it is
often more efficient to poll than to block the thread, which involves a context switch and the updating of thread
data structures. The system does not provide any implementations of spin locks because of their polling
nature, but you can easily implement them in specific situations.
○ Double-checked lock - A double-checked lock is an attempt to reduce the overhead of taking a lock by testing
the locking criteria prior to taking the lock. Because double-checked locks are potentially unsafe, the system
does not provide explicit support for them and their use is discouraged.

● Conditions
○ A condition is another type of semaphore that allows threads to signal each other when a certain condition is
true. Conditions are typically used to indicate the availability of a resource or to ensure that tasks are
performed in a specific order. When a thread tests a condition, it blocks unless that condition is already true. It
remains blocked until some other thread explicitly changes and signals the condition. The difference between
a condition and a mutex lock is that multiple threads may be permitted access to the condition at the same
time. The condition is more of a gatekeeper that lets different threads through the gate depending on some
specified criteria.
○ One way we might use a condition is to manage a pool of pending events. The event queue would use a
condition variable to signal waiting threads when there were events in the queue. If one event arrives, the
queue would signal the condition appropriately. If a thread were already waiting, it would be woken up
whereupon it would pull the event from the queue and process it. If two events came into the queue at roughly
the same time, the queue would signal the condition twice to wake up two threads.

● Performselector
○ Each request to perform a selector is queued on the target thread’s run loop and the requests are then
○ Processed sequentially in the order in which they were received.
● @synchronized
○ The @synchronized directive is a convenient way to create mutex locks on the fly in Objective-C code. The
@synchronized directive does what any other mutex lock would do—it prevents different threads from
acquiring the same lock at the same time.
https://developer.apple.com/library/ios/documentation/Cocoa/Conceptual/Multithreading/ThreadSafety/ThreadSafety.
html

Thread management ios
Each process (application) in OS X or iOS is made up of one or more threads, each of which
represents a single path of execution through the application's code. Every application starts with a
single thread, which runs the application's main function. Applications can spawn additional
threads, each of which executes the code of a specific function.
● Creating an Autorelease Pool
○ Managed memory model - strictly needed
○ Garbage collecting model - not necessary but using is not harmful
Because,
1. The top-level autorelease pool does not release its objects until the thread exits, long-lived threads should create
additional autorelease pools to free objects more frequently.
2. A thread that uses a run loop might create and release an autorelease pool each time through that run loop.
Releasing objects more frequently prevents your application’s memory footprint from growing too large, which can
lead to performance problems.

● Setting Up an Exception Handler
○ If our application catches and handles exceptions, the thread code should be prepared to catch any
exceptions that might occur. Although it is best to handle exceptions at the point where they might occur,
failure to catch a thrown exception in a thread causes your application to exit.
○ Installing a final try/catch in the thread entry routine allows to catch any unknown exceptions and provide an
appropriate response.

● Setting Up a Run Loop
○ To run code segment on a separate thread, there are two options.
■ The first option is to write the code for a thread as one long task to be performed
with little or no interruption, and have the thread exit when it finishes.
■ The second option is put the thread into a loop and have it process requests
dynamically as they arrive. This option, involves setting up the thread’s run loop.
● Terminating a Thread
○ Let it exit naturally(Recommended)
○ To kill the thread,

Threads
pthread
OS X and iOS provide C-based
support for creating threads using
the POSIX thread API. This
technology can actually be used in
any type of application (including
Cocoa and Cocoa Touch
applications) and might be more
convenient if you are writing your
software for multiple platforms.
#include <assert.h>
#include <pthread.h>
void* PosixThreadMainRoutine(void* data)
{
// Do some work here.
return NULL;
}
void LaunchThread()
{
// Create the thread using POSIX routines.
pthread_attr_t attr;
pthread_t posixThreadID;
int returnVal;
returnVal = pthread_attr_init(&attr);
assert(!returnVal);
returnVal = pthread_attr_setdetachstate(&attr, PTHREAD_CREATE_DETACHED);
assert(!returnVal);
int threadError = pthread_create(&posixThreadID, &attr, &PosixThreadMainRoutine,
NULL);
returnVal = pthread_attr_destroy(&attr);
assert(!returnVal);
if (threadError != 0)
{
// Report an error.
}
}

NSThread
NSThread is a simple Objective-C wrapper
around pthreads. This makes the code look
more familiar in a Cocoa environment. For
example, you can define a thread as a
subclass of NSThread, which encapsulates
the code you want to run in the background.
For the previous example, we could define an
NSThread subclass like this:
NSThread* myThread = [[NSThread alloc] initWithTarget:self
selector:@selector
(myThreadMainMethod:)
object:nil];
[myThread start]; // Actually create the thread
or
[NSThread detachNewThreadSelector:@selector(myThreadMainMethod:)
toTarget:self withObject:nil];

GCD(Grand Central Dispatch)
● Grand Central Dispatch (GCD) was introduced in OS X 10.6 and iOS 4 in order to make it
easier for developers to take advantage of the increasing numbers of CPU cores in consumer
devices.
● With GCD you don’t interact with threads directly anymore. Instead you add blocks of code to
queues
● GCD manages a thread pool behind the scenes.
● GCD decides on which particular thread your code blocks are going to be executed on, and it
manages these threads according to the available system resources.
● The other important change with GCD is that you as a developer think about work items in a
queue rather than threads. This new mental model of concurrency is easier to work with.

Dispatch Queues
● Dispatch queues allows us to execute arbitrary blocks of code either asynchronously or
synchronously
● All Dispatch Queues are first in – first out
● All the tasks added to dispatch queue are started in the order they were added to the
dispatch queue.
● Dispatch Queue Types
○ Serial (also known as private dispatch queue)
○ Concurrent
○ Main Dispatch Queue

Dispatch Sources
A dispatch source is a fundamental data type that coordinates the processing of specific low-level
system events. Grand Central Dispatch supports the following types of dispatch sources:
●Timer dispatch sources generate periodic notifications.
●Signal dispatch sources notify you when a UNIX signal arrives.
●Descriptor sources notify you of various file- and socket-based operations, such as:
○When data is available for reading
○When it is possible to write data
○When files are deleted, moved, or renamed in the file system
○When file meta information changes
●Process dispatch sources notify you of process-related events, such as:
○When a process exits
○When a process issues a fork or exec type of call
○When a signal is delivered to the process
●Some other system events

Dispatch Source Example
dispatch_source_t CreateDispatchTimer(uint64_t interval,
uint64_t leeway,
dispatch_queue_t queue,
dispatch_block_t block)
{
dispatch_source_t timer = dispatch_source_create(DISPATCH_SOURCE_TYPE_TIMER,
0, 0, queue);
if (timer)
{
dispatch_source_set_timer(timer, dispatch_walltime(NULL, 0), interval, leeway);
dispatch_source_set_event_handler(timer, block);
dispatch_resume(timer);
}
return timer;
}
void MyCreateTimer()
{
dispatch_source_t aTimer = CreateDispatchTimer(30ull * NSEC_PER_SEC,
1ull * NSEC_PER_SEC,
dispatch_get_main_queue(),
^{ MyPeriodicTask(); });
// Store it somewhere for later use.
if (aTimer)
{
MyStoreTimer(aTimer);
}

Operation Queues
● NSInvocationOperation
● NSBlockOperation
● NSOperation

NSInvocationOperation
@implementation MyCustomClass
- (NSOperation*)taskWithData:(id)data {
NSInvocationOperation* theOp = [[NSInvocationOperation alloc] initWithTarget:self
selector:@selector(myTaskMethod:) object:data];
return theOp;
}
// This is the method that does the actual work of the task.
- (void)myTaskMethod:(id)data {
// Perform the task.
}
@end
NSBlockOperation
NSBlockOperation* theOp = [NSBlockOperation blockOperationWithBlock: ^{
NSLog(@"Beginning operation.n");
// Do some work.
}];

NSOperation
@interface MyNonConcurrentOperation : NSOperation
@property id (strong) myData;
-(id)initWithData:(id)data;
@end
@implementation MyNonConcurrentOperation
- (id)initWithData:(id)data {
if (self = [super init])
myData = data;
return self;
}
-(void)main {
@try {
// Do some work on myData and report the results.
}
@catch(...) {
// Do not rethrow exceptions.
}
}
@end

Concurrent/ parallel programming

More Related Content

What's hot (20)

Viewers also liked (12)

Similar to Concurrent/ parallel programming (20)

Recently uploaded (20)

Concurrent/ parallel programming