Changes between Version 3 and Version 4 of user_synchro


Ignore:
Timestamp:
Oct 9, 2018, 1:36:04 PM (3 years ago)
Author:
alain
Comment:

--

Legend:

Unmodified
Added
Removed
Modified
  • user_synchro

    v3 v4  
    1717The 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.
    1818
    19 It can be used by muti-threaded user applications to synchronise user threads running in different clusters.
     19It 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.
    2020
    2121The 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.
    2222
    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 
     23For 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.
    2528
    2629== C) Condvar ==
     
    2831The 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.
    2932
     33It 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.
     34A condvar must always be associated to a mutex.
     35
     36The 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
     38For 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.
     44The three  functions wait(), signal() and broadcast() must be called by a thread holding the mutex associated to the condvar.
     45
    3046== D) Semaphore ==
    3147