home bbs files messages ]

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