There are two kind of semaphores implemented in Pliant.

method s request
  arg_rw Sem s

Request write access to the semaphore. Puts the current thread asleep until the semaphore is available, and then gets it. The semaphore allocation policy is expected to be fair. On the other hand, attempting to request a semaphore that you already own will lock forever.

method s release
  arg_rw Sem s

Releases write access to the semaphore.

method s rd_request
  arg_rw Sem s

Request read access to the semaphore. Several threads may get read access to the same semaphore at the same time, but no thread can get write access while one has read access.

method s rd_release
  arg_rw Sem s

Releases read access to the semaphore.

method s nowait_request -> success
  arg_rw Sem s ; arg CBool success

method s nowait_rd_request -> success
  arg_rw Sem s ; arg CBool success

Request write or read access to the semaphore, but do not wait for it. If the semaphore is currently locked, then the function simply returns false. Use with caution because if you loop on this, you busy loop and moreover loose fairness.

new in release 38
NestedSem works exactly the same as Sem but will not dead lock if a process tries to lock a semaphore it already owns.


Fast semaphores are good for doing proper access to a scalar object that needs to be read and written by several threads provided no extra computation is performed while the semaphore is owned.

method s request
  arg_rw FastSem s

Requests write access to the fast semaphore. Busy loops until the semaphore is available, and then gets it.

method s release
  arg_rw FastSem s

Releases write access to the fast semaphore.