Version 2 (modified by alain, 5 years ago) (diff)


This section describes the ALMOS-MKH implementation of the POSIX compliant, user-level synchronisation services: mutex, condvar, barrier and semaphore.

A) General Principles

All data structure defined by ALMOS-MKH to support the user-level, POSIX compliant, synchronization services are fully specific, and do NOT use the kernel level synchronization primitives described in section. does NOT use the

B) Mutex

The user level, POSIX compliant, mutex API is defined in the pthread library implemented by the pthread.h and pthread.c files.

It can be used by muti-threaded user applications to synchronise user threads running in different clusters.

A mutex is declared by a given user process as a pthread_mutex_t global variable. This user type is implemented by ALMOS-MKH as an unsigned long, but the value stored in user space is NOT used by the kernel. ALMOS-MKH uses only the mutex virtual address as an identifier for the mutex.

The kernel implementation of a mutex is defined in the remote_mutex.h and remote_mutex.c files.

For each user mutex, ALMOS-MKH creates a kernel remote_mutex_t structure, dynamically allocated in the reference cluster (i.e. in the cluster containing the reference process descriptor) by the remote_mutex_create() function, and destroyed by the remote_mutex_destroy() function, using RPC if the calling thread is not running in the reference cluster. The blocking remote_mutex_lock() function implements a descheduling policy when the lock is already taken by another thread : the calling thread is registered in a waiting queue, rooted in the remote_mutex_t structure, and the the calling thread is blocked on the THREAD_BLOCKED_MUTEX condition. The remote_mutex_unlock() function unblocks the first waiting thread in the queue without releasing the mutex if the queue is not empty.

C) Condvar

D) Semaphore

E) Barrier