Nikita Danilov wrote:
Howard Chu <[email protected]> writes:
> concurrency. It is the nature of such a system to encounter
> deadlocks over the normal course of operations. When a deadlock is
> detected, some thread must be chosen (by one of a variety of
> algorithms) to abort its transaction, in order to allow other
> operations to proceed to completion. In this situation, the chosen
> thread must get control of the CPU long enough to clean itself up,
What prevents transaction monitor from using, say, condition
variables to "yield cpu"? That would have an additional advantage of
blocking thread precisely until specific event occurs, instead of
blocking for some vague indeterminate load and platform dependent
amount of time.
Condition variables offer no control over which thread is waken up.
We're wandering into the design of the SleepyCat BerkeleyDB library
here, and we don't exert any control over that either. BerkeleyDB
doesn't appear to use pthread condition variables; it seems to construct
its own synchronization mechanisms on top of mutexes (and yield calls).
In this specific example, we use whatever BerkeleyDB provides and we're
certainly not about to write our own transactional embedded database
engine just for this.
--
-- Howard Chu
Chief Architect, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc
OpenLDAP Core Team http://www.openldap.org/project/
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
| |
 |