Forums before death by AOL, social media and spammers... "We can't have nice things"
|    soc.culture.quebec    |    More than just pale imitations of France    |    108,436 messages    |
[   << oldest   |   < older   |   list   |   newer >   |   newest >>   ]
|    Message 106,539 of 108,436    |
|    Wisdom90 to All    |
|    About composability of lock-based system    |
|    19 Nov 19 14:19:28    |
      From: d@d.d              Hello...                     About composability of lock-based systems now:              Design your systems to be composable. Among the more galling claims of       the detractors of lock-based systems is the notion that they are somehow       uncomposable:              “Locks and condition variables do not support modular programming,”       reads one typically brazen claim, “building large programs by gluing       together smaller programs[:] locks make this impossible.”9 The claim, of       course, is incorrect. For evidence one need only point at the       composition of lock-based systems such as databases and operating       systems into larger systems that remain entirely unaware of lower-level       locking.              There are two ways to make lock-based systems completely composable, and       each has its own place. First (and most obviously), one can make locking       entirely internal to the subsystem. For example, in concurrent operating       systems, control never returns to user level with in-kernel locks held;       the locks used to implement the system itself are entirely behind the       system call interface that constitutes the interface to the system. More       generally, this model can work whenever a crisp interface exists between       software components: as long as control flow is never returned to the       caller with locks held, the subsystem will remain composable.              Second (and perhaps counterintuitively), one can achieve concurrency and       composability by having no locks whatsoever. In this case, there must be       no global subsystem state—subsystem state must be captured in       per-instance state, and it must be up to consumers of the subsystem to       assure that they do not access their instance in parallel. By leaving       locking up to the client of the subsystem, the subsystem itself can be       used concurrently by different subsystems and in different contexts. A       concrete example of this is the AVL tree implementation used extensively       in the Solaris kernel. As with any balanced binary tree, the       implementation is sufficiently complex to merit componentization, but by       not having any global state, the implementation may be used concurrently       by disjoint subsystems—the only constraint is that manipulation of a       single AVL tree instance must be serialized.              Read more here:              https://queue.acm.org/detail.cfm?id=1454462                            Thank you,       Amine Moulat Ramdane.              --- SoupGate-Win32 v1.05        * Origin: you cannot sedate... all the things you hate (1:229/2)    |
[   << oldest   |   < older   |   list   |   newer >   |   newest >>   ]
(c) 1994, bbs@darkrealms.ca