Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.programming.threads > #5065 > unrolled thread

About composability of lock-based systems..

Back to article view | Back to comp.programming.threads

Contents

  About composability of lock-based systems.. Horizon68 <horizon@horizon.com> - 2019-06-29 12:28 -0700

#5065 — About composability of lock-based systems..

Hello,


About composability of lock-based systems..


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

And now about Message Passing Process Communication Model and Shared 
Memory Process Communication Model:


An advantage of shared memory model is that memory communication is 
faster as compared to the message passing model on the same machine.

However, shared memory model may create problems such as synchronization 
and memory protection that need to be addressed.

Message passing’s major flaw is the inversion of control–it is a moral 
equivalent of gotos in un-structured programming (it’s about time 
somebody said that message passing is considered harmful).

Also some research shows that the total effort to write an MPI 
application is significantly higher than that required to write a 
shared-memory version of it.



Thank you,
Amine Moulay Ramdane.

Thank you,
Amine Moulay Ramdane.

[toc] | [standalone]

Back to top | Article view | comp.programming.threads

csiph-web