action #6158
closedaction #4600: Multi-machine support
create synchronization primitives
Description
Synchronization primitives (for now only mutexes are considered) are needed to properly sync multi job interdependent tasks.
Backend:
- supported by DB table ($id, $name, $associted_job, $locked_by)
$id generated automatically for internal purposes (also primary key)
$name is id of the lock to be used in tests
$associated_job needed for auto cleanup and to create combined key with $name
$locked_by job, if not locked it is empty
ABI:
- mutex_create($name, $associated_job)
- mutex_lock($name, $associated_job)
- mutex_unlock($name, $associated_job)
- mutex_destroy($name, $associated_job)
API:
- mutex_create($name)
- mutex_lock($name)
- mutex_unlock($name)
Notes:
- when mutex is created it is automatically locked
- when mutex does not exists it is considered as locked (so that dependant jobs can immediatelly call mutex_lock without race)
- for now, API calls are considered to be blocking
Updated by oholecek about 9 years ago
Changes:
Notes¶
- when mutex is created it is automatically UNlocked
- API call is translated to ABI call by adding $associated_job id. This id is computed from parent job id. If there is no parent, current job id is used. If there are more parents, locks with $name are enumerated and when matching id for one of the parents is found, that id is used. This is possible by asuming and ensuring that $name is unique withing dependant group (but may not be unique between all locks present in database).
Examples:
A <- B, B calls mutex_lock('user_add'), lock manager get A by calling parent(B).
A <- C, C calls mutex_lock('user_add'), lock manager get [A,B] by calling parent(C), enumerates locks with name 'user_add' and find to whom 'user_add' lock belongs (can only be A or B or neither since 'user_add' lock is unique for [A,B,C])
B </
Updated by oholecek about 9 years ago
- Status changed from New to Resolved
At the end, test API remained as planned, but there is no ABI. Test runtime communicates directly with openQA scheduler using /api/v1/mutex/[lock|unlock]/lock_name calls. DB does not have separate $id key, only compound key $owner,$lock_name.