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

[[PageOutline]]

== 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 J. 
 * A '''mutex''' is declared by a given user process as a ''pthread_mutex_t'' global variable. 
 * A '''condvar'''  is declared by a given user process as a ''pthread_cond_t'' global variable. 
 * A '''barrier'''  is declared by a given user process as a ''pthread_barrier_t'' global variable. 
 * A '''semaphore''' is declared by a given user process as a ''sem_t'' global variable. 
All these user types are implemented by ALMOS-MKH as ''unsigned long'', but the value stored in user space is NOT used by the kernel. ALMOS-MKH uses only the virtual address as an identifier for a given synchronization variable.
For each type of variable, ALMOS-MKH defines a specific internal data structure described below.

== B) Mutex ==

The user level, POSIX compliant, mutex API is defined in the '''pthread''' library implemented by the [https://www-soc.lip6.fr/trac/almos-mkh/browser/trunk/libs/libpthread/pthread.h pthread.h] and [https://www-soc.lip6.fr/trac/almos-mkh/browser/trunk/libs/libpthread/pthread.c pthread.c] files.

It can be used by a muti-threaded user application to synchronize user threads running in different clusters. It allows a given thread to exclusive access to a shared user object.

The kernel implementation of a mutex is defined in the [https://www-soc.lip6.fr/trac/almos-mkh/browser/trunk/kernel/libk/remote_mutex.h remote_mutex.h] and [https://www-soc.lip6.fr/trac/almos-mkh/browser/trunk/kernel/libk/remote_mutex.c 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).
 * The '''remote_mutex_create()''' function allocates and initializes a mutex, using an RPC if if the calling thread is not running in the reference cluster.
 * The '''remote_mutex_destroy()''' function destroys a given mutex, 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 the waiting queue, rooted in the ''remote_mutex_t'' structure, and the the calling thread is blocked on the THREAD_BLOCKED_USERSYNC 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 ==

The user level, POSIX compliant, condvar API is defined in the '''pthread''' library implemented by the [https://www-soc.lip6.fr/trac/almos-mkh/browser/trunk/libs/libpthread/pthread.h pthread.h] and [https://www-soc.lip6.fr/trac/almos-mkh/browser/trunk/libs/libpthread/pthread.c pthread.c] files.

It can be used by a muti-threaded user application to synchronize user threads running in different clusters. It allows a given thread  to efficiently wait for a change in a shared user object.
A condvar must always be associated to a mutex.

The kernel implementation of a condvar is defined in the [https://www-soc.lip6.fr/trac/almos-mkh/browser/trunk/kernel/libk/remote_condvar.h remote_condvar.h] and [https://www-soc.lip6.fr/trac/almos-mkh/browser/trunk/kernel/libk/remote_condvar.c remote_condvar.c] files.

For each user condvar, ALMOS-MKH creates a kernel ''remote_condvar_t'' structure, dynamically allocated in the reference cluster (i.e. in the cluster containing the reference process descriptor).
 * The '''remote_condvar_create()''' function allocates and initializes a condvar, using an RPC if if the calling thread is not running in the reference cluster.
 * The '''remote_condvar_destroy()''' function destroys a given condvar, using RPC if the calling thread is not running in the reference cluster. 
 * The blocking '''remote_condvar_wait()''' function allows the calling thread to block on the  THREAD_BLOCKED_USERSYNC condition and to register in the waiting queue attached to the ''remote_condvar_t'' structure.
 * The '''remote_condvar_signal()''' function allows (another) thread to unblock the first blocked thread waiting on a given condvar.
 * The '''remote_condvar_broadcast()''' function allows (another) thread to unblock all threads waiting on a given condvar.
The three  functions wait(), signal() and broadcast() must be called by a thread holding the mutex associated to the condvar.

== D) Semaphore ==

== E) Barrier ==