Here is an extension of the meter description.
We address a problem with conventional thread ideas
I watched a recent panel discussing C++11.
They discussed the semantics of terminating a thread and suggested that killing a thread that held a lock presented an unsolved problem.
Keykos solves that problem within a pattern that I think is broadly applicable but perhaps less efficient.
Some collection of code shares direct access to a lock.
That collection is charged with keeping that lock unlocked except for short periods.
This is just part of ensuring integrity and availability of the data protected by the lock.
We realized that such code must run under a meter that is:
- sufficiently prompt for the purposes of any client requiring indirect access to the data,
- of duration sufficient to the data and its clients.
These requirements are standard for all objects relative to those who share them.
We quickly settled on a pair of closely related alternative strategies; either of these defined an object which encapsulated the locked data.
- The simple form was merely to decree that some domain would execute all the code that directly accessed the data, in which case no other lock was necessary than the single threaded nature of the domain.
- If the behavior of the object naturally associated with the data requires multiprogramming, one domain will not suffice and a classic lock is indicated.
This is the case when the performance of the native hardware suffices for the application but the cost of entering and leaving a domain does not.
This second pattern needs elaboration for the case where the code attempts and fails to get the lock.
Failure to get get the lock is presumably uncommon; if it is common then some other class of algorithm is indicated.
Upon failure, set a bit of the same scope of the lock and invoke a join object.
When we unlock the lock after the critical code, we must now test the bits of our various concurrencers and if it is on we know that we have blocked another concurrent domain who is waiting on its wait object—his
RETURN key is in a standard place.
This is like the kernel’s worrier problem that arose in the kernel.
Sometimes compare and swap is better.
This is a slight mess.
This may be a better mess.
paid for by the agency that ‘owns’ the lock and its data.
If someone needs to perform a transaction that requires locking that lock, he must call a domain that has actual write access to the lock and runs code from the ‘collection’.
If the caller is terminated the transaction is unperturbed, as it is running under a meter owned by whoever is responsible for lock integrity.
It is a mere matter of abstraction; code that can access the lock is not terminated when code needs indirect access to the lock.
When the transaction is complete it returns, continuation style, and the recipient has disappeared but the lock and what it protects are still intact.
Perhaps the above can be said in ocap terms as follows:
Objects are multi threaded and threads can naturally share mutable data and locks.
The object with the lock runs on its own meter whose lifetime must be great enough to protect the lock.
There are ramifications:
If the meter of the code that owns the lock, is subject to delay, then any client of that code will likewise be delayed.
I think this is an inherent problem.
Elaborate designs are possible where little more than the truly critical code, within the abstraction, runs under an unusually provisioned meter.
Indeed this is frequently the preferred way in Keykos since a single domain executes no more than one thread in most meanings of the word.
("Thread" is not a technical term in Keykos.)
This is sort of like an uninterruptible power supply that we see for critical low power applications.
The Eros, Capros, Coyotos family uses a Scheduler construct for meter like functions.