# Mutex Published articles for Mutex. This is one page of public article previews, not the complete archive. Follow Next page to continue. Summaries are not the original full articles. ## Tips for Saving Game Data in Godot DevFeed: [Tips for Saving Game Data in Godot]() Original publisher: [Read original article]() Published: 2026-08-21T00:00:00Z Content type: tutorial Language: en Sources: [Robin Ward]() Topics: [Godot](), [saving](), [Concurrent Programming](), [data](), [JSON](), [Hardware](), [Testing]() Tags: [bug](), [code](), [disk-space](), [game](), [games](), [json](), [mutex](), [os](), [saving](), [testing](), [thread](), [tips]() ### AI overview This tutorial describes a save-data approach for Godot games, based on experience shipping two games. It compares custom binary and JSON formats, recommends frequent debounced saves on a separate thread, checks available disk space, and discusses temporary-file replacement to reduce corrupted save-game reports. ### Source excerpt Saving game data is easy. Making your save code survive every kind of hardware failure is not. A lot of these issues will never show up during testing, but if your game reaches a wide audience with many different kinds of hard drives in different states of degradation, you will start to get bug reports about save games not working. I decided to write up my approach, learned over the course of shipping two Godot games, that has reduced our corrupted save game bug reports to virtually nothing. ## osmo-remsim - osmo-remsim 1.2.0 released DevFeed: [osmo-remsim - osmo-remsim 1.2.0 released]() Original publisher: [Read original article]() Author: lynxis Published: 2026-08-05T16:54:21Z Content type: release Language: en Sources: [Open Source Mobile Communications: News]() Topics: [bug](), [Concurrency](), [log management]() Tags: [bug](), [bug-fixes](), [client](), [crash](), [csv](), [deadlock](), [debug](), [issue](), [logging](), [mutex](), [tracker]() ### AI overview osmo-remsim 1.2.0 is a release containing stability and bug fixes across bankd, remsim-client, remsim-bankd, and related ASN.1 and logging code. The fixes address invalid CSV and TPDU handling, crashes, memory leaks, race conditions, signal handling, slot mapping, byte order, and a logging mutex deadlock. ### Source excerpt 1.2.0 contains stability fixes and bug fixes. [ Alexander Couzens ] * bankd: csv: fix crash on invalid lines * bankd: csv: fail on invalid csv lines * rspro_server: don't access the msg on error cases * rspro_util: asn1 decode: fix memleak when decoding fails * asn1: ber_decoder: disable stack size check on ctx = NULL * asn1: move asn_debug into librspro * Remove unconditional assignment of asn_debug = 0 * rspro_server: use correct byte order in log message "Bankd IP/Port changed to : [ Andreas Eversberg ] * Fix: Remove slot mapping at bankd when client disconnects * Fix: Prevent race conditions when accessing slotmap in bankd * Fix: Prevent bankd from exiting upon SIGPIPE * Fix unhandled (un)mapping events [ Harald Welte ] * remsim-client: Don't attempt to pass on illegal TPDU length * remsim-bankd: Don't pass on illegal TPDUs of illegal length * bankd: Avoid osmocom logging mutex deadlock in signal handling ## Safe Optimistic Lock Coupling DevFeed: [Safe Optimistic Lock Coupling]() Original publisher: [Read original article]() Author: Thomas Neumann (noreply@blogger.com) Published: 2026-04-29T10:22:56Z Content type: article Language: en Sources: [Database Architects]() Topics: [Concurrency](), [Concurrent Programming](), [Data structures](), [Scalability](), [race-condition]() Tags: [concurrent](), [cpu](), [data-structures](), [locking](), [locks](), [mutex](), [performance](), [race-condition](), [scalability](), [synchronization](), [thread](), [typesafety]() ### AI overview The article explains how lock coupling can limit the scalability of concurrent binary-tree lookups because readers contend on locks, especially at the root. It presents Optimistic Lock Coupling, in which readers validate version numbers without writes, and discusses the race-condition risk when values are used before validation. ### Source excerpt As the number of CPU cores keeps growing, the scalability of concurrent data structures becomes increasingly important. A data structure that works fine on 4 cores can become a bottleneck on 32, not because of algorithmic limitations, but because of how it synchronizes access. We illustrate that with a simple binary tree. Usually these data structures are protected by some kind of lock: struct Node { mutex lock; key_type key; value_type value; Node* left, *right; }; struct Tree { mutex lock; Node* root; }; When searching a value, we can traverse the data structure, lock the parts of the data we are currently touching, and release locks when we are done ("lock coupling"): option Tree::lookup(key_type key) { lock.lock_shared(); mutex* currentLock = &lock; Node* iter = root; option result; while (iter) { if (key == iter->key) { result = iter->value; break; } Node* next = (key < iter->key) ? iter->left : iter->right; if (next) next->lock.lock_shared(); currentLock->unlock(); currentLock = next ? &next->lock : nullptr; iter = next; } currentLock->unlock(); return result; } While conceptually simple, lock coupling has quite poor performance in practice. The problem is that it creates contention on the locks, in particular for the root node. Every lookup goes through the root node, thus the root node is constantly locked and unlocked. While there is no semantic contention between lookups, as all readers can read the root concurrently, there is physical contention on the lock itself, which limits scalability. This can be seen below, with concurrent lookups in a tree of 100,000 elements, executed on a 16-core / 32-thread 9950X3D. Lookup scalability: no locking vs lock coupling This contention problem can be solved by using Optimistic Lock Coupling, a synchronization technique where readers do not perform any writes. The key idea here is that writers lock as usual, and increase a version number when they are done updating. Readers read the version numb ## How to Prevent Race Conditions in Coroutines DevFeed: [How to Prevent Race Conditions in Coroutines]() Original publisher: [Read original article]() Author: author@typealias.com (Dave Leeds) Published: 2025-11-24T00:00:00Z Content type: tutorial Language: en Sources: [Dave Leeds on Kotlin - typealias.com]() Topics: [Coroutines](), [kotlin-coroutines](), [Kotlin](), [Concurrency]() Tags: [actor](), [atomicint](), [atomics](), [concurrency](), [coroutine](), [coroutines](), [how-to](), [kotlin](), [kotlin-coroutines](), [limitedparallelism](), [mutex](), [programming](), [race-condition](), [shared-mutable-state](), [state](), [stateflow](), [structured-concurrency]() ### AI overview This tutorial explains that Kotlin coroutines and structured concurrency do not automatically protect shared mutable state from race conditions. It introduces the issue using an example that creates 100,000 random bakery orders. ### Source excerpt Thanks to structured concurrency, there are a lot of concerns that we don't have to handle manually when working with Kotlin coroutines. For example, parent coroutines automatically wait for their children to complete before completing themselves. And when a parent coroutine is cancelled, its children are automatically cancelled, too. But when it comes to shared mutable state - mutable data that multiple coroutines could update at the same time - there's nothing magical in the design of coroutines to ensure that the state is updated properly. ## Fearless Concurrency Ep.5: Ensuring Memory Safety with Mutexes and RwLocks in Rust DevFeed: [Fearless Concurrency Ep.5: Ensuring Memory Safety with Mutexes and RwLocks in Rust]() Original publisher: [Read original article]() Published: 2024-11-08T00:00:00Z Content type: tutorial Language: en Sources: [William Kennedy]() Topics: [Concurrent Programming](), [Rust](), [Memory Safety](), [Programming]() Tags: [advanced-concurrency-rust](), [concurrency](), [concurrency-in-rust](), [concurrency-patterns-rust](), [concurrent-read-write-access-rust](), [data-sharing-in-multithreading](), [deadlock-avoidance-rust](), [embedding-mutex-in-structs](), [fearless-concurrency-rust](), [interior-mutability-rust](), [managing-shared-data-rust](), [memory-safety](), [mutex](), [mutexes-in-rust](), [optimizing-performance-rust-multithreading](), [rust](), [rust-concurrency-best-practices](), [rust-concurrency-tools](), [rust-data-synchronization](), [rust-interior-mutability-examples](), [rust-multithreading-performance](), [rust-mutex-integration](), [rust-mutex-vs-rwlock](), [rust-read-write-locks](), [rust-thread-management](), [rust-thread-safety](), [rust-thread-safety-techniques](), [rwlock-in-rust](), [rwlock-vs-mutex-rust](), [sync-trait-in-rust](), [sync-trait-rust](), [synchronization](), [thread](), [thread-safe-structs-rust]() ### AI overview Episode 5 of a Rust concurrency series explains RwLock for coordinating simultaneous reads and writes, along with interior mutability for embedding mutexes in structs. It advises limiting RwLock use to read-heavy cases, starting with mutexes to learn synchronization fundamentals, and avoiding deadlocks. The examples show how struct-level synchronization can simplify multithreaded code and reduce unnecessary serialization. ### Source excerpt Introduction: Welcome to Episode 5 of Fearless Concurrency in Rust! In this episode, Herbert Wolverson dives into advanced concurrency tools, focusing on RwLock for managing simultaneous reads and writes and the powerful concept of interior mutability. These tools provide developers with greater control over data sharing in multithreaded environments, enabling them to optimize for both performance and code simplicity in Rust. Read-Write Locks (RwLock): Manage concurrent read and write access efficiently. ## Fearless Concurrency Ep.4: Understanding Mutexes and Thread Safety in Rust DevFeed: [Fearless Concurrency Ep.4: Understanding Mutexes and Thread Safety in Rust]() Original publisher: [Read original article]() Published: 2024-10-25T00:00:00Z Content type: tutorial Language: en Sources: [William Kennedy]() Topics: [Concurrency](), [Rust](), [Programming](), [Deadlock]() Tags: [avoiding-race-conditions-in-rust](), [code](), [concurrency](), [concurrency-and-memory-management-in-rust](), [concurrency-in-rust](), [deadlock](), [how-to](), [managing-shared-data-in-rust](), [mutex](), [mutex-and-drop-trait-in-rust](), [mutexes-in-rust](), [rust](), [rust-concurrency-best-practices](), [rust-concurrency-guide](), [rust-drop-trait-in-concurrency](), [rust-multithreading-tutorial](), [rust-mutex-example](), [rust-mutex-vs-lock](), [rust-ownership-and-borrowing-in-concurrency](), [rust-thread-safety](), [rust-thread-safety-without-garbage-collection](), [safety](), [synchronization](), [thread](), [thread-synchronization-in-rust](), [understanding-poisoned-mutexes-in-rust]() ### AI overview This episode explains how Rust's ownership and borrowing rules support thread-safe multithreaded programming. It covers sharing data with mutexes, mutual exclusion, automatic lock cleanup, poisoned mutexes, and how Rust helps prevent data races, undefined behavior, and some deadlock issues. ### Source excerpt Introduction: Welcome to Episode 4 of Fearless Concurrency in Rust! In this episode, we explore how Rust's ownership and borrowing rules impact multithreaded programming, focusing on the complexities of managing memory in a concurrent environment. We'll break down how Rust's strict borrowing and ownership model ensures safety and prevents common pitfalls like data races and undefined behavior, making it an ideal choice for building reliable multithreaded applications. Thread Safety and Ownership: Managing variables across threads using Rust's ownership rules. ## Ep. 6: Exploring Concurrency Pitfalls: Rust vs. C++ and Go DevFeed: [Ep. 6: Exploring Concurrency Pitfalls: Rust vs. C++ and Go]() Original publisher: [Read original article]() Published: 2024-05-20T00:00:00Z Content type: comparison Language: en Sources: [William Kennedy]() Topics: [Concurrency](), [Rust](), [C++](), [Go Language](), [Programming](), [Error Handling]() Tags: [atomics](), [c-plus-plus](), [concurrency](), [error-handling](), [go](), [indicating-intent](), [mutex](), [pitfalls](), [reliable-codebases](), [rust](), [safety-concern](), [synchronization](), [threads](), [type-coercion]() ### AI overview This video compares how C++, Go, and Rust address data races in concurrent programs. It discusses unsynchronized shared access, Go's race-detection flag, and Rust's stricter mutability and synchronization rules, along with Rust's null-pointer avoidance and error handling. ### Source excerpt Introduction: Join Herbert in an insightful discussion on concurrency, where he tackles the complexities of data races and how various programming languages address them: Understand the crucial role of recognizing data races in concurrent programming and their potential impacts. See practical examples illustrating the chaos caused by data races and learn how Rust's compiler prevents such issues, ensuring program stability. Explore Rust's unique features like null pointer avoidance and reliable error handling, which enhance safety and reliability in concurrent programming tasks. ## Concurrent Programming in Kotlin: Ensuring Thread Safety with Mutex DevFeed: [Concurrent Programming in Kotlin: Ensuring Thread Safety with Mutex]() Original publisher: [Read original article]() Author: Kwabena Bio Berko Published: 2023-07-18T03:33:24Z Content type: tutorial Language: en Sources: [Engineering at Premise - Medium]() Topics: [Kotlin](), [Concurrent Programming](), [Coroutines](), [Database](), [Software Engineering]() Tags: [atomic](), [code](), [component](), [concurrency](), [concurrent](), [concurrent-programming](), [coroutine](), [coroutines](), [data](), [database](), [engineering](), [function](), [implementation](), [io](), [issue](), [kotlin](), [let](), [mobile-app-development](), [mutex](), [safety](), [suspend](), [thread]() ### AI overview This Kotlin tutorial explains how Mutex provides mutual exclusion when multiple threads or coroutines call a refresh function. It shows how locking can prevent duplicate network and database operations, avoid race conditions, and preserve atomicity, while withLock can suspend callers until the current lock is released. ### Source excerpt By Kwabena Bio Berko, Android Engineer Photo by Chris Ried on Unsplash I have recently been experimenting with mutual exclusion(Mutex), a concept in software engineering to solve race conditions when accessing shared resources. Let's assume we have a component with a refresh function that can be accessed from multiple threads or coroutines: https://medium.com/media/e19aa2a9d57bc105b841d28061a199b8/href In the implementation of this component, the function retrieves data from a remote resource and inserts it into the local database. However, these operations need to be atomic. Now, imagine if 10 threads call this function simultaneously, or even a few milliseconds apart. What happens? If you guessed that we make 10 network calls and 10 database IO operations to save the items, then you would be right, as confirmed by the below test: https://medium.com/media/9b279658dbf87021068ee21a913dc80e/hrefhttps://medium.com/media/81cdc164ad807fd45df77389c00bd4cc/href But that's not what we want. It's definitely not resource-friendly. To address this issue, we can use a Mutex. As the name suggests, a Mutex provides mutual exclusion for a specific portion of your code, imposing restrictions on the access to that portion in situations where multiple threads or coroutines may attempt to access it concurrently. In essence, Mutex allows only one thread or coroutine to work within the confines of that portion of the code at any given time. By introducing a Mutex in our refresh function, we can ensure that only one thread is executing the critical sections of the code, preventing race conditions and ensuring atomicity of the operations. https://medium.com/media/9d88a802b4c73f14ceb4d5527158af5d/href In the example above, whenever the refresh function is called, we check to see if the Mutex is already locked or been used. If not, we lock it and then perform our network call and save the results in our local database. This means that whenever another thread or coroutine calls this refresh ## MutexProtected: A C++ Pattern for Easier Concurrency DevFeed: [MutexProtected: A C++ Pattern for Easier Concurrency]() Original publisher: [Read original article]() Author: Andreas Kling Published: 2023-04-06T00:00:00Z Content type: tutorial Language: en Sources: [Andreas Kling]() Topics: [C++](), [Concurrency](), [Programming](), [Code](), [Deadlock]() Tags: [c-plus-plus](), [callback](), [class](), [concurrency](), [cpp](), [locks](), [mutex](), [programming](), [serenityos](), [technical](), [type-system]() ### AI overview This tutorial explains the MutexProtected pattern, which combines a mutex and protected data behind a callback-based C++ API. It compares manual locking in C with C++ RAII and the newer pattern, showing how the design reduces forgotten-lock errors and encodes the mutex-data relationship in the type system. It also notes that inconsistent ordering of multiple MutexProtected instances can still cause deadlocks. ### Source excerpt In this post, we will discuss the challenges of programming with locks and how the C++ language offers some useful tools to make it easier. We will start with an example in C and then use C++ to improve upon it in steps. The example APIs are based on real-life APIs from the SerenityOS kernel. ## Making unwinding through JIT-ed code scalable - Optimistic Lock Coupling DevFeed: [Making unwinding through JIT-ed code scalable - Optimistic Lock Coupling]() Original publisher: [Read original article]() Author: Thomas Neumann (noreply@blogger.com) Published: 2022-06-26T08:52:00Z Content type: article Language: en Sources: [Database Architects]() Topics: [Exception](), [Data structures](), [Concurrency]() Tags: [code](), [data-structure](), [exception](), [exception-handling](), [locking](), [mutex](), [performance](), [set]() ### AI overview The article explains a scalable approach to unwinding through JIT-ed code using a read-optimized B-tree with optimistic lock coupling. Writers use conventional exclusive lock coupling, while readers use version locks and validate their reads so they can run in parallel when writes are uncommon. ### Source excerpt This article is part of the series about scalable unwinding that starts here. When thinking about exception handling it is reasonable to assume that we will have far more unwinding requests than changes to the unwinding tables. In our setup, the tables only change when JITed code is added to or removed from the program. That is always expensive to begin with due the mprotect calls, TLB shootdowns, etc. Thus we can safely assume that we will have at most a few hundred updates per second even in extreme cases, probably far less. Lookups however can easily reach thousands or even millions per second, as we do one lookup per frame. This motivates us to use a read-optimized data structure, a b-tree with optimistic lock coupling: Writers use traditional lock coupling (lock parent node exclusive, lock child node exclusive, release parent node, lock child of child, etc.), which works fine as long as there is not too much contention. Readers however have to do something else, as we expect thousands of them. One might be tempted to use a rw-lock for readers, but that does not help. Locking an rw-lock in shared mode causes an atomic write, which makes the threads fight over the cache line of the lock even if there is no (logical) contention. Instead, we use version locks, where readers do no write at all: // Common logic for version locks struct version_lock { // The lock itself. The lowest bit indicates an exclusive lock, // the second bit indicates waiting threads. All other bits are // used as counter to recognize changes. // Overflows are okay here, we must only prevent overflow to the // same value within one lock_optimistic/validate // range. Even on 32 bit platforms that would require 1 billion // frame registrations within the time span of a few assembler // instructions. uintptr_t version_lock; }; #ifdef __GTHREAD_HAS_COND // We should never get contention within the tree as it rarely changes. // But if we ever do get contention we use these for waiting static __gthre ## Making unwinding through JIT-ed code scalable - Replacing the gcc hooks DevFeed: [Making unwinding through JIT-ed code scalable - Replacing the gcc hooks]() Original publisher: [Read original article]() Author: Thomas Neumann (noreply@blogger.com) Published: 2022-06-26T08:48:00Z Content type: article Language: en Sources: [Database Architects]() Topics: [gcc](), [patches](), [JIT]() Tags: [atomic](), [gcc](), [jit](), [lock-free](), [mutex](), [patches]() ### AI overview This article explains patches to GCC that replace a globally locked list of unwinding frames with a read-optimized B-tree. The change enables concurrent registration, deregistration, and lock-free lookups, while keeping frames immutable during unwinding on platforms that support atomics. ### Source excerpt This article is part of the series about scalable unwinding that starts here. As discussed in the previous article, the gcc mechanism does not scale because it uses a global lock to protect its list of unwinding frames. To solve that problem, we replace that list with a read-optimized b-tree that allows for concurrent reads and writes. In this article we just discuss the patches to gcc necessary to enable that mechanism, the b-tree itself is discussed in subsequent articles. We start by replacing the old fast path mechanism with a b-tree root: index 8ee55be5675..d546b9e4c43 100644 --- a/libgcc/unwind-dw2-fde.c +++ b/libgcc/unwind-dw2-fde.c @@ -42,15 +42,34 @@ see the files COPYING3 and COPYING.RUNTIME respectively. If not, see #endif #endif +#ifdef ATOMIC_FDE_FAST_PATH +#include "unwind-dw2-btree.h" + +static struct btree registered_frames; + +static void +release_registered_frames (void) __attribute__ ((destructor (110))); +static void +release_registered_frames (void) +{ + /* Release the b-tree and all frames. Frame releases that happen later are + * silently ignored */ + btree_destroy (®istered_frames); +} + +static void +get_pc_range (const struct object *ob, uintptr_t *range); +static void +init_object (struct object *ob); + +#else + /* The unseen_objects list contains objects that have been registered but not yet categorized in any way. The seen_objects list has had its pc_begin and count fields initialized at minimum, and is sorted by decreasing value of pc_begin. */ static struct object *unseen_objects; static struct object *seen_objects; -#ifdef ATOMIC_FDE_FAST_PATH -static int any_objects_registered; -#endif #ifdef __GTHREAD_MUTEX_INIT static __gthread_mutex_t object_mutex = __GTHREAD_MUTEX_INIT; @@ -78,6 +97,7 @@ init_object_mutex_once (void) static __gthread_mutex_t object_mutex; #endif #endif +#endif When the platform supports atomics (ATOMIC_FDE_FAST_PATH), we replace the whole mechanism with one b-tree, whose root is registered_frames. Neither the ## Making unwinding through JIT-ed code scalable DevFeed: [Making unwinding through JIT-ed code scalable]() Original publisher: [Read original article]() Author: Thomas Neumann (noreply@blogger.com) Published: 2022-06-26T08:46:00Z Content type: tutorial Language: en Sources: [Database Architects]() Topics: [C++](), [Exception](), [gcc](), [Concurrency](), [Jule](), [systems]() Tags: [c-plus-plus](), [compiler](), [concurrent](), [exception](), [gcc](), [hooks](), [jit](), [lock-free](), [mutex](), [series]() ### AI overview This article explains why C++ exception unwinding remains effectively single-threaded when JIT-ed code is registered. It describes limitations in gcc and glibc mechanisms and introduces a gcc patch using a read-optimized lock-free b-tree to support parallel unwinding without atomic writes. ### Source excerpt Exceptions are a very handy mechanism to propagate errors in C++ programs, but unfortunately they do not scale very well. In all common C++ implementations the unwinding mechanism takes global lock during unwinding, which has disastrous consequences when the number of threads is high. On a machine with 256 hardware context we see worse-than-single-threaded behavior even for relatively modest failure rates. Fortunately the Florian Weimer fixed one contention point in gcc 12 on systems with glibc 2.35 or newer, which gives us scalable exceptions as long as no JIT-ed code has been registered. Unfortunately our system does register JIT-ed code... Which means exception unwinding in our code base is still single-threaded in practice. But we can fix that by teaching gcc to store the unwinding information in a read-optimized b-tree, which allows for fully parallel unwinding without any atomic writes. There is a gcc patch that does just that, but unfortunately it is quite involved and difficult to review. This article series thus explains all parts of the patch and shows how a read-optimized b-tree can be implemented lock-free. In order to keep the article length somewhat reasonable, the discusses is broken into parts: The problem (this article) Replacing the gcc hooks Optimistic Lock Coupling The b-tree b-tree operations When unwinding exceptions, the compiler has to find the corresponding unwinding information for every call frame on the stack between the throw and the catch. gcc uses two different mechanisms for that: For ahead-of-time compiled code it asks glibc to find the unwinding information using either dl_iterate_phdr (on older systems) or _dl_find_object (on systems with glibc 2.35 or newer). Note that this mapping is not static, as shared libraries could be added or removed at any time, potentially during a concurrent unwind. For that reason dl_iterate_phdr was protected by a global mutex, which clearly does not scale. _dl_find_object avoids that mutex by using a ## Leveraging the Semaphore concept in Coroutines to limit the parallelism 🔀 DevFeed: [Leveraging the Semaphore concept in Coroutines to limit the parallelism 🔀]() Original publisher: [Read original article]() Author: Shreyas Patil Published: 2022-04-01T12:57:35Z Content type: tutorial Language: en Sources: [Shreyas Patil's Blog]() Topics: [kotlin-coroutines](), [Kotlin](), [Concurrency](), [Concurrent Programming]() Tags: [android](), [concurrency](), [concurrent-programming](), [coroutines](), [how-to](), [java](), [kotlin](), [kotlin-coroutines](), [multithreading](), [mutex](), [synchronization](), [threads]() ### AI overview A tutorial explaining semaphores in Kotlin coroutines, including binary and counting semaphores, and how permits limit parallel access to shared resources. ### Source excerpt Explore the concept of Semaphores in Kotlin Coroutines. Learn how to limit parallelism and manage resource access in concurrent programming. ## Thread Safety in C++ and Rust DevFeed: [Thread Safety in C++ and Rust]() Original publisher: [Read original article]() Author: Haberman Published: 2021-12-18T00:00:00Z Content type: article Language: en Sources: [Josh Haberman]() Topics: [C++](), [Rust](), [Concurrency](), [Concurrent Programming]() Tags: [atomic](), [c-plus-plus](), [concurrent](), [mutex](), [rust](), [safety](), [synchronization](), [thread]() ### AI overview The article compares thread-safety terminology and models in C++ and Rust. It explains C++ distinctions between thread-safe and thread-compatible types, including synchronization costs, and introduces Rust traits for safely sharing or moving types between threads. ### Source excerpt Lately I've been experimenting with Rust, and I want to report some of what I've learned about thread-safety. I am an enthusiastic dabbler in Rust: I spend most of my time in C and C++, but I'm always looking for an excuse to learn more about Rust's approach to the techniques I use every day in C and C++. When studying Rust's threading model, I came to see some correspondence between C++ and Rust terminology that I had not seen published previously. Here are my findings, which hopefully can help people with C++ background understand Rust (or vice-versa). C++ The C++ standard does not define the term "thread-safe", but it is common practice now within the C++ community to define it in the following way: thread-safe: A type is thread-safe if it is is safe to invoke any of its methods concurrently. To provide this guarantee, a type must generally take some special measures to avoid data races, eg. using a mutex or atomic operations internally. This generally comes with performance and/or complexity costs, so most types will not be thread-safe. thread-compatible: A type is thread-compatible if it is safe to invoke const methods concurrently. Any concurrent call to a non-const method must be synchronized by the caller. Most types in C++ are thread-compatible, as this guarantee comes mostly comes for free: it happens naturally for any type that is const-correct (ie. avoids mutable members or const_cast). Thread-compatible types compose nicely and avoid synchronization overheads. Suppose you have 10 thread-compatible objects that you want to access concurrently together. You can wrap a Mutex around all 10 and pay only a single synchronization cost. If you have 10 thread-safe objects, you pay 10 separate synchronization costs as each of them perform their own internal synchronization. If you are using an object in only one thread, you may not need synchronization at all, but the thread-safe type won't know this and will pay the cost regardless. For all of these reasons, thr ## Friday Q&A 2017-10-27: Locks, Thread Safety, and Swift: 2017 Edition DevFeed: [Friday Q&A 2017-10-27: Locks, Thread Safety, and Swift: 2017 Edition]() Original publisher: [Read original article]() Author: Mike Ash Published: 2017-10-27T11:28:00Z Content type: article Language: en Sources: [Mike Ash]() Topics: [Swift](), [Concurrency](), [Deadlock](), [Objective-C]() Tags: [concurrent](), [deadlock](), [locks](), [mutex](), [objective-c](), [safety](), [swift](), [thread](), [threading](), [threads]() ### AI overview An updated guide to locks and thread safety in Swift, covering mutex types, their behavior, and related Apple and Objective-C synchronization facilities. ### Source excerpt Back in the dark ages of Swift 1, I wrote an article about locks and thread safety in Swift. The march of time has made it fairly obsolete, and reader Seth Willits suggested I update it for the modern age, so here it is! (Read More) ## Google SoC lwIP Report Week 11 DevFeed: [Google SoC lwIP Report Week 11]() Original publisher: [Read original article]() Published: 2016-08-08T00:00:00Z Content type: opinion Language: en Sources: [Front Page on ReactOS Website]() Topics: [lwIP](), [Concurrency](), [Concurrent Programming](), [Kernel](), [implementation](), [test]() Tags: [concurrent](), [free](), [kernel](), [lwip](), [mutex](), [open-source](), [os](), [react](), [reactos](), [tcp](), [testing](), [tests](), [threads](), [win32](), [winapi]() ### AI overview A week 11 development report describing efforts to address thread-safety problems in lwIP and the author's TCP_CONTEXT structures. The author used mutexes to serialize access and modified semaphore behavior so that lwIP threads could not run concurrently. ### Source excerpt This past week, I have primarily focused on thread-safety. Three weeks ago, I discovered that lwIP's core code is not thread-safe. When left unmodified, each lwIP thread will access several unprotected global linked lists as well as use a set of global variables to process any and all incoming packets. One option to solve this problem was to modify the core code so the global data was protected from concurrent access. ## USB stack improvements GSoC - Week 8 DevFeed: [USB stack improvements GSoC - Week 8]() Original publisher: [Read original article]() Published: 2016-07-18T00:00:00Z Content type: article Language: en Sources: [Front Page on ReactOS Website]() Topics: [USB](), [Concurrency](), [implementation]() Tags: [controllers](), [free](), [gsoc](), [handling](), [implementation](), [improvements](), [mutex](), [open-source](), [os](), [react](), [reactos](), [safety](), [state](), [synchronization](), [usb](), [win32](), [winapi]() ### AI overview A week-eight GSoC progress report describes USB stack work in usbhub, including stability fixes, handling of removal and surprise-removal IRPs, synchronization of the FDO child list with a guarded mutex, and PnP state tracking. ### Source excerpt I have spent this week on improvements of realization and done stability fixes in usbhub PDO/FDO. I have prepared usbhub FDO's handling of removal and surprise-removal IRPs. We'll receive surprise-removal IRP on HUB unexpected removal, or on USB controller removal from PCI port. Here hub should "let know" all its children that their parent is removed and on next removal they also can be removed. For now this code path can't be tested because none of our host controllers can be removed now(they are failing query remove). ## Concurrent queue in C DevFeed: [Concurrent queue in C]() Original publisher: [Read original article]() Author: Marek Published: 2012-09-10T22:00:00Z Content type: tutorial Language: en Sources: [Marek Majkowski]() Topics: [C](), [Concurrent Programming](), [Concurrency](), [Data structures](), [Algorithms, Complexity]() Tags: [c](), [concurrent](), [implementation](), [lock-free](), [memory](), [mutex](), [pointers](), [queue](), [thread](), [threads]() ### AI overview This article explains the design and implementation of a thread-safe concurrent queue in C. It compares a mutex-based approach with a lock-free design using CAS, discusses CPU memory ordering and pointer-related memory reclamation problems, and presents a blocking queue implementation using locks. ### Source excerpt Concurrent queue in C I needed a queue implementation written in C for one of my ever-experimental projects. The complex part was to make it thread-safe - it was going to be used for exchanging data between threads. Usually, I'd just take the doubly linked list implementation from the linux kernel1, wrap it in a mutex and quickly move on to another challenge. This time though, I decided to make sure the queue is as efficient as possible.