| 23 | | 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. |
| 24 | | |
| | 23 | 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). |
| | 24 | * 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. |
| | 25 | * The '''remote_mutex_destroy()''' function destroys a given mutex, using RPC if the calling thread is not running in the reference cluster. |
| | 26 | * 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. |
| | 27 | * The '''remote_mutex_unlock()''' function unblocks the first waiting thread in the queue without releasing the mutex if the queue is not empty. |
| | 33 | 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. |
| | 34 | A condvar must always be associated to a mutex. |
| | 35 | |
| | 36 | 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. |
| | 37 | |
| | 38 | 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). |
| | 39 | * 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. |
| | 40 | * The '''remote_condvar_destroy()''' function destroys a given condvar, using RPC if the calling thread is not running in the reference cluster. |
| | 41 | * 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. |
| | 42 | * The '''remote_condvar_signal()''' function allows (another) thread to unblock the first blocked thread waiting on a given condvar. |
| | 43 | * The '''remote_condvar_broadcast()''' function allows (another) thread to unblock all threads waiting on a given condvar. |
| | 44 | The three functions wait(), signal() and broadcast() must be called by a thread holding the mutex associated to the condvar. |
| | 45 | |
