Groups | Search | Server Info | Keyboard shortcuts | Login | Register

Groups > comp.lang.pascal.misc > #2722

The convoy phenomenon

Show all headers | View raw

Hello...


I have just read the following IBM Research Report about Locks and 
convoying:

The convoy phenomenon

https://blog.acolyer.org/2019/07/01/the-convoy-phenomenon/

And i think that it is not so smart, because i am a white arab that is 
smart like a genius :), and i have invented a the Holy Grail of Locks 
that is more powerful than the above, it is a scalable Fast Mutex
that is faster than the scalable MCS Lock, read about it in my
following thoughts:

I have invented a scalable algorithm that is a scalable fast Mutex that 
is remarkable and that is the Holy Grail of scalable Locks, it has the 
following characteristics, read my following thoughts to understand:

About fair and unfair locking..

I have just read the following lead engineer at Amazon:

Highly contended and fair locking in Java

https://brooker.co.za/blog/2012/09/10/locking.html

So as you are noticing that you can use unfair locking that can have 
starvation or fair locking that is slower than unfair locking.

I think that Microsoft synchronization objects like the Windows critical 
section uses unfair locking, but they still can have starvation.

But i think that this not the good way to do, because i am an inventor 
and i have invented a scalable Fast Mutex that is much more powerful , 
because with my scalable Fast Mutex you are capable to tune the 
"fairness" of the lock, and my Fast Mutex is capable of more than that, 
read about it on my following thoughts:

More about research and software development..

I have just looked at the following new video:

Why is coding so hard...

https://www.youtube.com/watch?v=TAAXwrgd1U8

I am understanding this video, but i have to explain my work:

I am not like this techlead in the video above, because i am also an 
"inventor" that has invented many scalable algorithms and there 
implementions, i am also inventing effective abstractions, i give you an 
example:

Read the following of the senior research scientist that is called Dave 
Dice:

Preemption tolerant MCS locks

https://blogs.oracle.com/dave/preemption-tolerant-mcs-locks

As you are noticing he is trying to invent a new lock that is preemption 
tolerant, but his lock lacks some important characteristics, this is why 
i have just invented a new Fast Mutex that is adaptative and that is 
much much better and i think mine is the "best", and i think you will 
not find it anywhere, my new scalable Fast Mutex has the following 
characteristics:

1- Starvation-free
2- Tunable fairness
3- It keeps efficiently and very low its cache coherence traffic
4- Very good fast path performance
5- And it has a good preemption tolerance.
6- It is faster than scalable MCS lock
7- Not prone to convoying.

And 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

And you have to look here at our DelphiConcurrent and FreepascalConcurrent:

https://sites.google.com/site/scalable68/delphiconcurrent-and-freepascalconcurrent

Thank you,
Amine Moulay Ramdane.

Back to comp.lang.pascal.misc | Previous | Next | Find similar

Thread

The convoy phenomenon Wisdom91 <d1@d1.d1> - 2020-07-14 16:24 -0400

csiph-web