• About Hardware Transactional Memory and my invention that is my powerfu

    From Wisdom90@21:1/5 to All on Tue Dec 31 10:45:02 2019

    About Hardware Transactional Memory and my invention that is my powerful
    Fast Mutex:

    "As someone who has used TSX to optimize synchronization primitives, you
    can expect to see a ~15-20% performance increase, if (big if) your
    program is heavy on disjoint data access, i.e. a lock is needed for correctness, but conflicts are rare in practice. If you have a lot of
    threads frequently writing the same cache lines, you are probably going
    to see worse performance with TSX as opposed to traditional locking. It
    helps to think about TSX as transparently performing optimistic
    concurrency control, which is actually pretty much how it is implemented
    under the hood."

    Read more here:


    So as you are noticing, HTM (hardware transactional memory) and TM can
    not replace locks when doing IO and for highly contended critical
    sections, this is why i have invented my following powerful Fast Mutex:

    More about research and software development..

    I have just looked at the following new video:

    Why is coding so hard...


    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

    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 Fast Mutex has the following characteristics:

    1- Starvation-free
    2- Good fairness
    3- It keeps efficiently and very low the cache coherence traffic
    4- Very good fast path performance (it has the same performance as the
    scalable MCS lock when there is contention.)
    5- And it has a decent preemption tolerance.

    this is how i am an "inventor", and i have also invented other scalable algorithms such as a scalable reference counting with efficient support
    for weak references, and i have invented a fully scalable Threadpool,
    and i have also invented a Fully scalable FIFO queue, and i have also
    invented other scalable algorithms and there inmplementations, and i
    think i will sell some of them to Microsoft or to
    Google or Embarcadero or such software companies.

    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:


    Thank you,
    Amine Moulat Ramdane.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)