xapi-project / xen-api / 11032347750
78%
master: 80%

LAST BUILD BRANCH: gh-readonly-queue/master/pr-6829-a6aa3635396a1991f303b2f5731266d394547b2a
DEFAULT BRANCH: master
Ran
Jobs 1
Files 37
Run time 1min
Badge
Embed ▾
README BADGES
x

If you need to use a raster PNG badge, change the '.svg' to '.png' in the link

Markdown

Textile

RDoc

HTML

Rst
coverage: 78.279%. Remained the same
11032347750

push

github

web-flow 
CP-51574: Add explicit reentrant lock to Db_lock (#6011)

Update `Db_lock` to use an explicit reentrant (recursive) mutex pattern.

This is a pretty standard implementation. The way it works is that
threads compete to become the "holder" of the lock. The current holder
of the lock is identified using thread identifiers (integers) and
read/written from/to atomically (by way of `Atomic.t`). If attempting to
acquire the lock (i.e. atomically `compare_and_set` the holder, with the
expected current value as physically equal to `None`) fails, then the
thread begins to wait. Waiting threads wait using a condition variable
to avoid busy waiting. The lock can be acquired several times after it
is acquired by the calling thread, but releasing it must ensure that
every lock is matched by a corresponding unlock (the thread must
relinquish every "hold" it has on the lock). Upon successfully releasing
its holds on the lock, the thread that is relinquishing control resets
the holder (to `None`) and uses the condition variable to signal a
waiting thread to wakeup (and attempt to become the holder).

To make this pattern safe and not expose too many details, an interface
file (`db_lock.mli`) is introduced. This interface does not expose the
details of the underlying lock, but rather the single function:

```ocaml
val with_lock : (unit -> 'a) -> 'a
```

which ensures the invocation of its argument is properly sandwiched
between code that correctly acquires and releases the lock (taking care
to avoid holding onto the lock during exceptional circumstances, e.g. by
way of an exception that is unhandled). Code written to use the database
lock currently only use this interface to acquire the `Db_lock`, so no
other changes are required.

A follow-up change may be to enforce the same usage pattern for the
global database flush lock, which is seemingly only used in the same
way.

-----

Ring3: BST+BVT (205351) all looks fine (so far) except an SDK-related
test, which appears t... (continued)

3456 of 4415 relevant lines covered (78.28%)

0.78 hits per line

Jobs
ID Job ID Ran Files Coverage
1 python3.11 - 11032347750.1 37
78.28
 GitHub Action Run
Source Files on build 11032347750