Multithreaded Programming

Thread and child Process

1. Threads may be managed by either user-level library functions or the OS kernal. Child process is created by fork system call managed by OS kernel.

2. All threads in a process share the same data and code segment. A child process has its own copy of virtual address space. So thread uses less resource then child process.

3. If a thread calls exit or exec function, it terminates all the threads in the same process. If a child process calls the exit or exec functions, its parent process is not affected.

4. If a thread modifies a global variable in process, the changes are visible to other threads in the same process. This problem does not exists with child and parent process.

Thread structure

1. Thread ID (unique to process)

2. Runtime-stack

3. Set of registers (Program counter and stack pointer)

4. Signal mask

5. Schedule priority

6. Thread specific storage

Newly created thread inherits- Signal mask- Schedule priority- Set of registers

When the first thread is created in a process, two threads are actually created. 1. To execute specified functions

2. Carry on the execution of process. This terminates when main function returns or when it calls pthread_exit.

Creating Thread

#include <pthread.h> int pthread_create (pthread_t *thread,

const pthread_attr_t *attr, void *(*start_routine) (void *), void *arg);

thread: unique identifier for the new thread returned by the subroutine. attr: attribute object that may be used to set thread attributes. NULL for

the default values. start_routine: routine that the thread will execute once it is created. arg: A single argument that may be passed to start_routine. It must be

passed by reference as a pointer cast of type void. NULL may be used if no argument is to be passed.

Initially, main() program comprises a single, default thread. All other threads must be explicitly created by the programmer.

pthread_create creates a new thread and makes it executable. This routine can be called any number of times from anywhere within code.

Thread Attribute

By default, a thread is created with certain attributes. Some of these attributes can be changed by the programmer via the thread attribute object.

int pthread_attr_init(pthread_attr_t *atrr_p)

int pthread_attr_destroy(pthread_attr_t *atrr_p)

are used to initialize/destroy the thread attribute object.

Thread Attribute

Other routines used to query/set specific attributes in the thread attribute object are:

Contention scope : pthread_attr_getscope

Options: PTHREAD_SCOPE_PROCESS

PTHREAD_SCOPE_SYSTEM

Stack size : pthread_attr_getstacksize

Stack Address: pthread_attr_getstackaddr

Detach State: pthread_attr_getdetachstate

Options: PTHREAD_CREATE_DETACHED

PTHREAD_CREATE_JOINABLE

Schedule Policy: pthread_attr_getschedpolicy

Schedule Parameters: pthread_attr_getschedparm

Thread Attributeint main(int argc, char *argv[]) {

int t;pthread_attr_t attr; pthread_t thread; size_t stacksize; pthread_attr_init(&attr); pthread_attr_getstacksize (&attr, &stacksize); printf("Default stack size = %li\n", stacksize);

if( pthread_create(&thread, &attr, dowork, (void *)t) == -1)perror(“Pthread_create”);

….….return 0;

}

Terminating Threads

- Thread returns from its starting routine (main routine for the initial thread )

- Thread makes a call to the pthread_exit()- Thread is canceled by another thread via the pthread_cancel

routine- Entire process is terminated due to a call to either the exec or exit

subroutines.

pthread_exit is used to explicitly exit a thread. pthread_exit() routine is called after a thread has completed its work and is no longer required to exist.

If main() finishes before the threads it has created, and exits with pthread_exit(), the other threads will continue to execute. Otherwise, they will be automatically terminated when main() finishes.

Terminating Threadspthread_exit() routine does not close files; any files opened inside the thread will remain open after the thread is terminated.

Pthread Creation and Termination #include <pthread.h> #include <stdio.h> void *PrintHello(void *threadid) {

int tid; tid = (int)threadid; printf("Hello World! It's me, thread #%d!\n", tid);pthread_exit(NULL);

} int main (int argc, char *argv[]) {

pthread_t thread; int t;

printf("In main: creating thread %d\n", t); if(pthread_create(&thread, NULL, PrintHello, (void *)t) == -1)

perror(“pthrerad_crerate);pthread_exit(NULL);

}

Thread Argument passingPass multiple argument via a structure.struct thread_data_t{

int thread_id; char *message;

}; struct thread_data_t thread_data; void *PrintHello(void *threadarg) {

struct thread_data_t *my_data;.. ..

my_data = (struct thread_data *) threadarg; taskid = my_data->thread_id; hello_msg = my_data->message; ...

} int main (int argc, char *argv[]) {

... thread_data.thread_id = t; thread_data.message = messages; pthread_create(&thread, NULL, PrintHello, (void *) &thread_data);

... pthread_exit(NULL);

}

Thread Management

Joining and Detaching thread

int pthread_join(pthread_t tid, void** status);

int pthread_detach(void* status);

Joining- "Joining" is one way to accomplish synchronization between

threads - The pthread_join() subroutine blocks the calling thread until the

specified thread_id thread terminates. - Target thread's termination return status can obtain if it was

specified in the target thread's call to pthread_exit(). - When a thread is created, one of its attributes defines whether it is

joinable or detached. Only threads that are created as joinable can be joined. If a thread is created as detached, it can never be joined.

Thread ManagementTo explicitly create a thread as joinable or detached, the attr argument in the

pthread_create() routine is used.

The typical 4 step process is: 1. Declare a pthread attribute variable of the pthread_attr_t data type2. Initialize the attribute variable with pthread_attr_init()3. Set the attribute detached status with pthread_attr_setdetachstate()4. When done, free library resources used by the attribute with

pthread_attr_destroy()

Detaching The pthread_detach() routine can be used to explicitly detach a thread even

though it was created as joinable.

Thread Managementint pthread_sigmask(int mode, const sigset_t *set, sigset_t *oldset);

int pthread_kill(pthread_t tid, int signum);

Options for mode :

SIG_BLOCK, SIG_UNBLOCK, SIG_SETMASK

Sigset_t set, oldset

Sigemptyset(&set);

Sigaddset(&set, SIGINT);

If(pthread_sigmask(SIG_BLOCK, &set, &oldset))

perror(“pthread_sigmask”);

Mutex LocksMutex lock serialize the execution of threads.A typical sequence in the use of a mutex is as follows:

1. Create and initialize a mutex variable 2. Several threads attempt to lock the mutex 3. Only one succeeds and that thread owns the mutex 4. The owner thread performs some set of actions 5. The owner unlocks the mutex 6. Another thread acquires the mutex and repeats the process 7. Finally the mutex is destroyed

When several threads compete for a mutex, the losers block at that call - an unblocking call is available with "trylock" instead of the "lock" call. NOTE : When protecting shared data, we need to make sure that every thread needs to use a mutex . If 5 threads are updating the same data, but only one uses a mutex, the data can still be corrupted.

Mutex LocksCreating and Destroying Mutex

int pthread_mutex_init (pthread_mutex_t *mutex, pthread_mutexattr_t *attr) int pthread_mutex_destroy (pthread_mutex_t *mutex) int pthread_mutexattr_init(pthread_mutexattr_t *attr);int pthread_mutexattr_destroy(pthread_mutexattr_t *attr);

Mutex variables must be declared with type pthread_mutex_t, and must be initialized before they can be used. There are two ways to initialize a mutex variable:

Statically, when it is declared. For example: pthread_mutex_t mymutex = PTHREAD_MUTEX_INITIALIZER;

Dynamically, with the pthread_mutex_init() routine. This method permits setting mutex object attributes, attr.

NOTE: The mutex is initially unlocked.

Mutex Locks

Locking and Unlocking Mutexes

int pthread_mutex_lock(pthread_mutex_t *mutex);int pthread_mutex_trylock(pthread_mutex_t *mutex);int pthread_mutex_unlock(pthread_mutex_t *mutex);

The pthread_mutex_lock() routine is used by a thread to acquire a lock on the specified mutex variable. If the mutex is already locked by another thread, this call will block the calling thread until the mutex is unlocked.

pthread_mutex_trylock() will attempt to lock a mutex. However, if the mutex is already locked, the routine will return immediately with a "busy" error code. This routine may be useful in preventing deadlock conditions.

Mutex LocksExample:int  counter = 0; pthread_mutex_t mymutex; void *function() { pthread_mutex_lock( & mymutex ); counter++; printf("Counter value: %d\n",counter); pthread_mutex_unlock( & mymutex ); }int main (int argc, char *argv[]){

pthread_mutex_init(&mymutex, NULL);pthread_create(...) pthread_join( ..)pthread_mutex_destroy(&mymutex);

pthread_exit(NULL);}

Conditional Variable

Condition variable are used to block threads until certain conditions become true. Condition variables are usually used with mutex locks so that multiple threads can wait on the same condition variable.

1. Thread acquires a mutex lock, but is blocked by a condition variable pending the occurrence of a specific condition.

2. While thread is blocked, the mutex lock it acquires is released automatically.

3. When another thread modifies the state of the specific condition, it signals the condition variable to unblock the thread

4. When the thread is unblocked, the mutex lock is reacquired automatically, and the thread tests the condition again.

5. If the condition remains false, the thread is again blocked by the condition variable.

6. If the condition is true, the thread releases the mutex lock and proceeds with its execution.

Conditional Variable

Creating and Destroying Condition Variables

int pthread_cond_init(pthread_cond_t *restrict cond, const pthread_condattr_t *restrict attr);

int pthread_cond_destroy(pthread_cond_t *cond);Int pthread_condattr_init(pthread_condattr_t *attr); int pthread_condattr_destroy(pthread_condattr_t *attr);

Condition variables must be declared with type pthread_cond_t, and must be initialized before they can be used. There are two ways to initialize a condition variable:

Statically, when it is declared. For example: pthread_cond_t myconvar = PTHREAD_COND_INITIALIZER;

Dynamically, with the pthread_cond_init() routine. The ID of the created condition variable is returned to the calling thread through the cond parameter.

Conditional Variable

Waiting and Signaling on Condition Variables

int pthread_cond_wait(pthread_cond_t *restrict condition , pthread_mutex_t *restrict mutex);

int pthread_cond_broadcast(pthread_cond_t * condition);

int pthread_cond_signal(pthread_cond_t * condition);

• pthread_cond_wait() blocks the calling thread until the specified condition is signalled.

• This routine should be called while mutex is locked, and it will automatically release the mutex while it waits.

• After signal is received and thread is awakened, mutex will be automatically locked for use by the thread.

Conditional Variable

• The pthread_cond_signal() routine is used to signal (or wake up) another thread which is waiting on the condition variable. It should be called after mutex is locked, and must unlock mutex in order for pthread_cond_wait() routine to complete.

• The pthread_cond_broadcast() routine should be used instead of pthread_cond_signal() if more than one thread is in a blocking wait state.

• Proper locking and unlocking of the associated mutex variable is essential when using these routines.

Failing to lock the mutex before calling pthread_cond_wait() may cause it NOT to block.

Failing to unlock the mutex after calling pthread_cond_signal() may not allow a matching pthread_cond_wait() routine to complete (it will remain blocked).

Conditional Variable

conditional.c

Spin Lock

#include <pthread.h> int pthread_spin_init(pthread_spinlock_t *lock, int pshared); int pthread_spin_lock(pthread_spinlock_t *lock); int pthread_spin_trylock(pthread_spinlock_t *lock); int pthread_spin_unlock(pthread_spinlock_t *lock); int pthread_spin_destroy(pthread_spinlock_t *lock);

• A thread waiting for a spinlock does not relinquish its CPU, but performs a busy loop.

• As the context switch overhead is saved, spinlocks usually give better performance on multi-processor systems than other synchronization methods.

• local interrupts are disabled when a thread acquires a spinlock. Spinlocks should therefore be locked only for short periods of time.

• On uni-processor machines, acquiring a spinlock has no other effect than disabling interrupts.

Spin Lock

spin_vs_mutex.cpp

Thread Specific Dataint pthread_key_create(pthread_key_t *key, void (*destructor)(void*)); void *pthread_getspecific(pthread_key_t key);int pthread_setspecific(pthread_key_t key, const void *value);int pthread_key_delete(pthread_key_t key);

• The pthread_key_create() function shall create a thread-specific data key visible to all threads in the process.

• Although the same key value may be used by different threads, the values bound to the key by pthread_setspecific() are maintained on a per-thread basis and persist for the life of the calling thread.

• Upon key creation, the value NULL shall be associated with the new key in all active threads.

• The thread-specific data values associated with key need not be NULL at the time pthread_key_delete() is called. It is the responsibility of the application to free any application storage or perform any cleanup actions for data structures related to the deleted key or associated thread-specific data in any threads; this cleanup can be done either before or after pthread_key_delete() is called .

Thread Specific Datapthread_once_t once_control = PTHREAD_ONCE_INIT; int pthread_once(pthread_once_t *once_control,

void (*init_routine)(void));

• The first call to pthread_once() by any thread in a process, with a given once_control, shall call the init_routine with no arguments.

• Subsequent calls of pthread_once() with the same once_control shall not call the init_routine.

• On return from pthread_once(), init_routine shall have completed.

pthread_key_t key;pthread_once_t key_once = PTHREAD_ONCE_INIT;

void make_key(){ pthread_key_create(&key, NULL);}

pthread_once(&key_once, make_key);

CORBA

What is CORBA ?

• Common Object Request Broker Architecture• Communication infrastructure for distributed objects

Useful for • Developing distributed applications• Locating remote objects on a network and Sending messages to

those objects• Any Language• Any Host on network• Any Platform

CORBA Architecture

Client Server

ORB ORB

request response

“Object Bus”

ORB

• Object Request Broker• Handles all communication among objects• Each host (machine) has its own ORB• ORBs know how to talk to each other• ORB also provides basic services to client

Responsibilities• Find the object implementation for the request• Prepare the object implementation to receive the request• Communicate the data making up the request• Retrieve results of request

ORB

• Not a separate process• Library code that executes in-process• Listens to TCP ports for connections

One port per local object• Opens TCP sockets to other objects

N ports per remote machine

IDL

• Interface Definition Language• Defines protocol to access objects• Language-independent• It defines the service that an object can provide.

Example:

module Calc {

interface Adder {

long add(in long x, in long y);

}

}

Defines an object called Adder with a method called add

Stub and Skeleton

Stub – lives on client

Stub – lives on server– receives requests from stub– talks to true remote object– delivers response to stub

Stub and Skeleton

IIOPORB

Client Host Machine

Client Object

ORB

Server Host Machine

Stub

Remote Object

Skeleton

Internet Inter-Orb Protocol

IDL to C++ mapping

IDL C++

module namespace

interface abstract class

operation member function

attribute pair of functions

exception exception

IDL to C++ mapping

IDL C++

short CORBA::Short

long CORBA::Long

long long CORBA::LongLong

unsigned short CORBA::UShort

unsigned long CORBA::ULong

unsigned long long CORBA::ULongLong

float CORBA::Float

double CORBA::Double

long double CORBA::LongDouble

char CORBA::Char

string CORBA::char *

boolean CORBA::Boolean

octet CORBA::Octet (unsigned char)

Object Adapters

An object adapter is a framework for implementing CORBA objects. It provides an API that object implementations use for various low level services.

According to the CORBA specification, an object adapter is responsible for the following functions:– Generation and interpretation of object references – Method invocation – Security of interactions – Object and implementation activation and deactivation – Mapping object references to the corresponding object

implementations – Registration of implementations

Basic Object Adapter (BOA)• One of the main tasks of the BOA is to support on-demand object activation. • When a client issues a request, the BOA determines

– if the object is currently running and if so, it delivers the request to the object.

– If the object is not running, the BOA activates the object and then delivers the request.

The BOA defines four different models for object activation:• Shared Server

– Multiple active objects share the same server. The server services requests from multiple clients. The server remains active until it is deactivated or exits.

• Unshared Server– Only one object is active in the server. The server exits when the client

that caused its activation exits.• Server per Method

– Each request results in the creation of a server. The server exits when the method completes.

• Persistent server– The server is started by an entity other than the BOA (you, operating

services, etc.). Multiple active objects share the server.

Portable Object Adapter (POA)

• According to the specification, "The intent of the POA, as its name suggests, is to provide an object adapter that can be used with multiple ORB implementations with a minimum of rewriting needed to deal with different vendors' implementations."

• The POA is also intended to allow persistent objects -- at least, from the client's perspective. That is, as far as the client is concerned, these objects are always alive, and maintain data values stored in them, even though physically, the server may have been restarted many times, or the implementation may be provided by many different object implementations.

• the implementer has more control over the object's identity, state, storage, and lifecycle.

• Transparent object activation

• Multiple distinct POAs in a single server with different policies and namespaces

Example

calculator.idl

Client.ccServer.cc

Makefile

calculator.hcalculator.cc

Run.sh

Thank You

jyotikumar.mishra@tcs.com