t3_1dk4zsc

Overview of JVM Threads: Understanding Multithreading in Java

t3_1b02mf6

An Introduction to Flynn’s taxonomy and the classification of computer architecture

t3_1azx5ru

Atomics And Concurrency

t3_191lp08

How to stop Linux threads cleanly

t3_16wbuif

50 years later, is Two-Phase Locking the best we can do?

t3_14vxkrq

Haiku's (Kernel) Condition Variables API: Design & Implementation

t3_14qeiko

I feel like Marky-Z's plans for next Thursday might revive this subreddit quite a bit...

[https://www.telegraph.co.uk/business/2023/07/04/twitter-rival-meta-threads-instagram-elon-musk-mark-zuckerberg/](https://www.telegraph.co.uk/business/2023/07/04/twitter-rival-meta-threads-instagram-elon-musk-mark-zuckerberg/)

<div class="md"><p>I feel like Marky-Z&#39;s plans for next Thursday might revive this subreddit quite a bit...</p>

<p><a href="https://www.telegraph.co.uk/business/2023/07/04/twitter-rival-meta-threads-instagram-elon-musk-mark-zuckerberg/">https://www.telegraph.co.uk/business/2023/07/04/twitter-rival-meta-threads-instagram-elon-musk-mark-zuckerberg/</a></p>
</div>

New life for this subreddit...?

t3_10njcpe

It's a common exercise in programming to synchronize access to data between threads. A simple mutex or other critical section tool will do the job. But sometimes, performance matters.

The problem with mutex's, or regular locks in high level languages, is that the waiting thread may be put to sleep since it cannot access the resource it wants.  And this behavior is usually desirable - except when it isn't.

There is a time cost associated with putting the waiting thread(s) to sleep and waking them when the resource is ready.

A simple heuristic can be used to determine whether you should try to upgrade regular wait locks to spin locks. A spin lock is where the thread actively tries to access the shared resource and doesn't go to sleep.

(h): if the shared resource is guaranteed to be locked for a sufficiently short period of time.

While working in [Orvina](https://github.com/webbersmak/Orvina), performance increased dramatically with a careful selection of locks to upgrade to spin locks - and the effort was less trouble than what was expected.

There are likely many programs out in the wild that would experience real world benefits with more diligence in the choice of locking mechanism implemented. It would be quite the feat if compilers could deduce or suggest a specific lock type and insert the correct one. Perhaps that's one improvement AI will contribute to.

https://preview.redd.it/c9t2dpu1ctea1.jpg?width=768&format=pjpg&auto=webp&s=da63c8768e2ab7d2176ff2e727ba4c0d5a717b0a

<div class="md"><p>It&#39;s a common exercise in programming to synchronize access to data between threads. A simple mutex or other critical section tool will do the job. But sometimes, performance matters.</p>

<p>The problem with mutex&#39;s, or regular locks in high level languages, is that the waiting thread may be put to sleep since it cannot access the resource it wants.  And this behavior is usually desirable - except when it isn&#39;t.</p>

<p>There is a time cost associated with putting the waiting thread(s) to sleep and waking them when the resource is ready.</p>

<p>A simple heuristic can be used to determine whether you should try to upgrade regular wait locks to spin locks. A spin lock is where the thread actively tries to access the shared resource and doesn&#39;t go to sleep.</p>

<p>(h): if the shared resource is guaranteed to be locked for a sufficiently short period of time.</p>

<p>While working in <a href="https://github.com/webbersmak/Orvina">Orvina</a>, performance increased dramatically with a careful selection of locks to upgrade to spin locks - and the effort was less trouble than what was expected.</p>

<p>There are likely many programs out in the wild that would experience real world benefits with more diligence in the choice of locking mechanism implemented. It would be quite the feat if compilers could deduce or suggest a specific lock type and insert the correct one. Perhaps that&#39;s one improvement AI will contribute to.</p>

<p><a href="https://preview.redd.it/c9t2dpu1ctea1.jpg?width=768&amp;format=pjpg&amp;auto=webp&amp;s=da63c8768e2ab7d2176ff2e727ba4c0d5a717b0a">https://preview.redd.it/c9t2dpu1ctea1.jpg?width=768&amp;format=pjpg&amp;auto=webp&amp;s=da63c8768e2ab7d2176ff2e727ba4c0d5a717b0a</a></p>
</div>

Don't fear the spin lock

t3_10nmx0i

t3_1056c64

Rust Atomics and Locks by Mara Bos

t3_s9auz3

When you accidentally start a 120 core job on a 160 core machine

The importance of Correctness in concurrent algorithms

Thread Safety in C++ and Rust

Using atomics for thread synchronization in C++ | Just Software Solutions

/r/threads hit 1k subscribers yesterday

Working of video streaming in a multi-core processor

Can't protect a pointer without a store-load fence

A Lock-Free Persistent Queue

Events and Threads in .NET

Throughput vs Latency and Lock-Free vs Wait-Free

Using Quiescent States to Reclaim Memory

The promises and challenges of std::async task-based parallelism in C++11

New Concurrent Hash Maps for C++

C++11 threads, affinity and hyperthreading

Fast lookups with memory_order_consume

Stupid RCU Tricks: Hand-over-hand traversal of linked list using SRCU

Multithreading for Gamedev Students

New Concurrency Features in C++14

An example of atomic_thread_fence()

The Dos and Don'ts of Multithreading [PDF]

Lock-free by Example: Towards an Interesting Lock-free MPMC Queue

Multithreading, concurrency and parallelism.

Not related to Meta/Instagram/FB - see [ThreadsApp](/r/ThreadsApp) instead.

<div class="md"><p>Multithreading, concurrency and parallelism.</p>

<p>Not related to Meta/Instagram/FB - see <a href="/r/ThreadsApp">ThreadsApp</a> instead.</p>
</div>

<div class="md"><p>Multithreading, concurrency and parallelism.</p>
</div>

threads

1,620 Subscribers

New life for this subreddit...?

Don't fear the spin lock

Working of video streaming in a multi-core processor