# atomic Published articles for atomic. This is one page of public article previews, not the complete archive. Follow Next page to continue. Summaries are not the original full articles. ## 【etcd】单 Raft 组与服务器角色：Leader、Follower、Learner 与 request 路由 DevFeed: [【etcd】单 Raft 组与服务器角色：Leader、Follower、Learner 与 request 路由]() Original publisher: [Read original article]() Author: Liao Tonglang Published: 2026-08-26T00:00:00Z Content type: article Language: zh Sources: [土法炼钢 - 系统与基础设施]() Topics: [etcd](), [Raft](), [gRPC]() Tags: [apiserver](), [apply](), [atomic](), [commit](), [compaction](), [distributed](), [etcd](), [etcdserver](), [follower](), [kubernetes](), [leader](), [learner](), [linearizable](), [raft](), [request](), [single-raft-group](), [v3](), [v3-5](), [v3-5-33](), [wal](), [watch]() ### AI overview This article explains how etcd v3.5.33 embeds a single Raft group, separates EtcdServer responsibilities from the Raft library, and routes requests across Leader, Follower, and Learner roles. It covers gRPC write forwarding, linearizable and serializable reads, and the handling of watch, lease, and mutating requests. ### Source excerpt 钉清 etcd v3.5.33 单 Raft 组拓扑、EtcdServer 与 go.etcd.io/raft/v3 边界、Leader/Follower/Learner 角色及 gRPC 写读路由；与 distributed/13 分工。 ## Design tokens: The building blocks of a design system DevFeed: [Design tokens: The building blocks of a design system]() Original publisher: [Read original article]() Published: 2026-08-18T00:00:00Z Content type: article Language: en Sources: [Aha! Engineering Blog]() Topics: [Design system](), [ui](), [CSS](), [consistency]() Tags: [atomic](), [component](), [css](), [design](), [design-system](), [source-of-truth](), [structure](), [tokens](), [ui](), [variables]() ### AI overview This article explains how design tokens provide a shared language for visual design attributes in a scalable design system. It contrasts tokens with hard-coded values, describes primitive and semantic tokens, and discusses using the Design Tokens Community Group standard to connect design and engineering. ### Source excerpt Implementing a design system at scale is often less about the pixels and more about the language we use to describe them. As a Senior Software Engineer at Aha! I've spent a lot of time thinking about how we can build a UI that is not only beautiful, ## How R8 made Kotlin Coroutines on Android 2x faster DevFeed: [How R8 made Kotlin Coroutines on Android 2x faster]() Original publisher: [Read original article]() Author: Android Developers (noreply@blogger.com) Published: 2026-07-27T13:00:00Z Content type: article Language: en Sources: [Android Developers Blog]() Topics: [Coroutines](), [Kotlin](), [R8](), [Android](), [Compose](), [Programming]() Tags: [android](), [android-gradle-plugin](), [app-performance](), [atomic](), [compose](), [coroutines](), [jetpack-compose](), [kotlin](), [perfetto](), [performance](), [programming](), [r8]() ### AI overview This article explains how R8 in AGP 9.2.0 optimizes Atomic*FieldUpdater calls into Unsafe variants, improving common operations by 2x to 4x. The optimization particularly benefits kotlinx.atomicfu and can make launching and cancelling Kotlin coroutines up to 2x faster. It also describes how coroutine overhead affected Jetpack Compose performance and how ART method traces helped identify bottlenecks. ### Source excerpt Posted by Andrei Shikov, Senior Software Engineer, Android Toolkit and Jonathan Starup, Software Engineer, R8 Team Starting from AGP 9.2.0, R8 optimizes most Atomic*FieldUpdater calls into Unsafe variants that perform 2x to 4x better on common operations. This has a particularly large impact on the kotlinx.atomicfu library that implements atomics for kotlinx.coroutines, making launching and cancelling coroutines up to 2x faster. In order to get the benefits, update your AGP to 9.2.0 or above. With the majority of Android apps adopting Kotlin as their main language of choice, kotlinx.coroutines has become a de-facto standard for asynchronous programming. The library offers a well-designed and structured way of managing concurrent flows that is native to Kotlin. Jetpack Compose was no exception, adopting coroutines for managing pointer events, animations and other interactions. At the time of writing, most concurrent APIs in Compose call suspend functions under the hood and are launching and/or cancelling coroutines to handle updates. As the Compose team started to investigate performance, coroutines were discovered to be a bottleneck for many operations that happen outside of composition. As an example, 80% of the time spent on creating and updating Modifier.clickable was consumed by launching and cancelling internal coroutines that handled InteractionSource updates. Based on those observations, much of early performance work was focused on removing coroutines from the default path and delaying initialization until necessary. The cost of a coroutine The easiest way to analyze a function's internal behavior on Android is to capture an Android Runtime (ART) method trace. An ART method trace is a tool that records the execution flow of an app, showing exactly which methods are called, their order, and how much time is spent in each, allowing developers to identify performance bottlenecks. For an empty LaunchedEffect { } call, it would look something like this: LaunchedE ## How R8 made Kotlin Coroutines on Android 2x faster DevFeed: [How R8 made Kotlin Coroutines on Android 2x faster]() Original publisher: [Read original article]() Author: Android Developers (noreply@blogger.com) Published: 2026-07-27T13:00:00Z Content type: article Language: en Sources: [Android Developers Blog](), [Android Developers Blog]() Topics: [Coroutines](), [Kotlin](), [R8](), [Android](), [Compose](), [Programming]() Tags: [android](), [android-gradle-plugin](), [app-performance](), [atomic](), [compose](), [coroutines](), [kotlin](), [performance](), [programming](), [r8]() ### AI overview This article explains how R8 optimization in AGP 9.2.0 improves Kotlin coroutines performance on Android. By optimizing AtomicFieldUpdater calls, the change makes launching and cancelling coroutines up to twice as fast, addressing coroutine-related bottlenecks in Jetpack Compose and other Android operations. ### Source excerpt Posted by Andrei Shikov, Senior Software Engineer, Android Toolkit and Jonathan Starup, Software Engineer, R8 Team Starting from AGP 9.2.0, R8 optimizes most Atomic*FieldUpdater calls into Unsafe variants that perform 2x to 4x better on common operations. This has a particularly large impact on the kotlinx.atomicfu library that implements atomics for kotlinx.coroutines, making launching and cancelling coroutines up to 2x faster. In order to get the benefits, update your AGP to 9.2.0 or above. With the majority of Android apps adopting Kotlin as their main language of choice, kotlinx.coroutines has become a de-facto standard for asynchronous programming. The library offers a well-designed and structured way of managing concurrent flows that is native to Kotlin. Jetpack Compose was no exception, adopting coroutines for managing pointer events, animations and other interactions. At the time of writing, most concurrent APIs in Compose call suspend functions under the hood and are launching and/or cancelling coroutines to handle updates. As the Compose team started to investigate performance, coroutines were discovered to be a bottleneck for many operations that happen outside of composition. As an example, 80% of the time spent on creating and updating Modifier.clickable was consumed by launching and cancelling internal coroutines that handled InteractionSource updates. Based on those observations, much of early performance work was focused on removing coroutines from the default path and delaying initialization until necessary. The cost of a coroutine The easiest way to analyze a function's internal behavior on Android is to capture an Android Runtime (ART) method trace. An ART method trace is a tool that records the execution flow of an app, showing exactly which methods are called, their order, and how much time is spent in each, allowing developers to identify performance bottlenecks. For an empty LaunchedEffect { } call, it would look something like this: LaunchedE ## Cloud Topics: Level Zero garbage collection DevFeed: [Cloud Topics: Level Zero garbage collection]() Original publisher: [Read original article]() Author: Oren Leiman Published: 2026-05-19T00:00:00Z Content type: article Language: en Sources: [Redpanda]() Topics: [Cloud](), [distributed-systems](), [Raft](), [systems]() Tags: [architecture](), [atomic](), [cloud](), [distributed-systems](), [engineering](), [garbage-collection](), [raft](), [storage](), [systems]() ### AI overview This article explains how Redpanda Cloud Topics safely garbage-collects temporary Level Zero (L0) objects after their data has been reorganized into Level One (L1) objects. It describes an epoch-based design and per-partition state for determining when L0 objects can be removed without data loss or unnecessary storage use. ### Source excerpt How Redpanda Cloud Topics tracks the lifecycle of temporary L0 objects and determines when they're safe to delete, without risking data loss or runaway storage costs. Read more. ## BitFields API: Type-Safe Bit Packing for Lock-Free Data Structures DevFeed: [BitFields API: Type-Safe Bit Packing for Lock-Free Data Structures]() Original publisher: [Read original article]() Author: Peter Dillinger Published: 2025-12-31T00:00:00Z Content type: tutorial Language: en Sources: [RocksDB]() Topics: [rocksdb](), [C++](), [Data structures](), [Cache](), [Code]() Tags: [atomic](), [blog](), [c-plus-plus](), [cache](), [concurrent](), [efficiency](), [implementation](), [lock-free]() ### AI overview This article introduces RocksDB's BitFields API, a type-safe, zero-overhead C++ abstraction for packing multiple logical fields into atomic variables. It explains how the API helps manage packed state and describes its use in the essentially lock-free HyperClockCache. ### Source excerpt Modern concurrent data structures increasingly rely on atomic operations to avoid the overhead of locking. A valuable but under-utilized technique for maximizing the effectiveness of atomic operations is bit packing--fitting multiple logical fields into a single atomic variable for algorithmic simplicity and efficiency. However, language support for bit packing does not guarantee dense packing, and manually managing bit manipulation quickly becomes error-prone, especially when dealing with complex state machines. To address this in RocksDB, we have developed a reusable BitFields API, a type-safe, zero-overhead abstraction for bit packing in C++. This works in conjunction with clean wrappers for std::atomic for powerful and relatively safe bit-packing of atomic data. For broader use, a variant of the code has been proposed for adding to folly. The Problem: Managing Packed Bit Fields Consider HyperClockCache, an essentially lock-free cache implementation in RocksDB, which was refactored to use this BitFields API. It is a hash table built on slots that can each hold a cache entry and relevant metadata. For atomic simplicity and efficiency, all the essential metadata for each slot is packed into a single 64-bit value: The reference count and eviction metadata are together encoded into acquire and release counters, 30 bits each. The possible states of {empty, under construction/destruction, occupied+visible, and occupied+invisible} are encoded into three state bits (instead of two, for easier decoding and manipulation). A hit bit is used for secondary cache integration. Traditionally, you might write code like this: 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 // Old approach: manual bit manipulation constexpr uint64_t kAcquireCounterShift = 0; constexpr uint64_t kReleaseCounterShift = 30; constexpr uint64_t kCounterMask = 0x3FFFFFFF; constexpr uint64_t kHitBitShift = 60; constexpr uint64_t k ## Testing crash recovery features in a CI environment DevFeed: [Testing crash recovery features in a CI environment]() Original publisher: [Read original article]() Author: andreacorbellini Published: 2025-09-09T00:05:00Z Content type: article Language: en Sources: [Andrea Corbellini]() Topics: [Filesystems](), [btrfs](), [Linux](), [Rust]() Tags: [atomic](), [btrfs](), [filesystem](), [information-technology](), [linux](), [rust]() ### AI overview A technical article describes atomic file updates in a Rust crate, using temporary files, synchronization, and atomic renaming to ensure a file contains either its old or new contents after a crash. It also discusses Linux anonymous temporary files and their limitations, including filesystem support and btrfs. ### Source excerpt About two years ago I wrote a Rust crate to fulfill this promise: If a crash occurs while updating a file, the file either contains the old contents, or the new contents, nothing in between. This crate essentially solves the following problem: when you update a file, generally you open it, truncate it, write to it block-by-block, and eventually close it. The problem with ... ## No more disks: the architecture behind stateless compute in ClickHouse Cloud DevFeed: [No more disks: the architecture behind stateless compute in ClickHouse Cloud]() Original publisher: [Read original article]() Author: Tom Schreiber Published: 2025-07-09T00:00:00Z Content type: article Language: en Sources: [ClickHouse Blog]() Topics: [clickhouse](), [Cloud](), [Databases](), [Apache Iceberg]() Tags: [architecture](), [atomic](), [building](), [catalog](), [clickhouse](), [cloud](), [cloud-native](), [latency](), [low-latency](), [scale](), [state](), [stateless](), [storage]() ### AI overview This post explains how ClickHouse Cloud achieved fully stateless compute by introducing an in-memory database engine powered by a Shared Catalog. Compute nodes no longer depend on local disks, enabling fast elastic provisioning, rapid wake-ups, and stateless processing across native and open data formats. ### Source excerpt ClickHouse Cloud compute is now fully stateless. This post introduces the final piece that made it possible, a new in-memory database engine powered by a Shared Catalog, and walks through how we got there. ## Fearless Concurrency Ep.6: Understanding Rust ARC for Efficient Multithreading DevFeed: [Fearless Concurrency Ep.6: Understanding Rust ARC for Efficient Multithreading]() Original publisher: [Read original article]() Published: 2024-11-21T00:00:00Z Content type: tutorial Language: en Sources: [William Kennedy]() Topics: [Rust](), [Concurrency](), [Concurrent Programming](), [data]() Tags: [arc-best-practices](), [arc-for-performance](), [arc-in-rust](), [arc-memory-management](), [arc-ownership-model](), [arc-shared-resources](), [arc-vs-garbage-collection](), [arc-with-mutex](), [arc-with-rwlock](), [atomic](), [atomic-reference-counting](), [best-practices](), [concurrency](), [concurrency-in-rust](), [efficient-multithreading-rust](), [examples](), [interior-mutability-arc](), [lightweight-memory-management](), [memory](), [multithreading](), [multithreading-with-arc](), [pitfalls](), [rust](), [rust-arc-tutorial](), [rust-arc-use-cases](), [rust-concurrency-tools](), [rust-shared-ownership](), [rust-thread-safe-programming](), [thread-safe-data-sharing](), [use-cases]() ### AI overview This tutorial explains Rust's Atomic Reference Counting (Arc) for sharing ownership of data across threads. It covers reference-counted memory management, cloning, performance implications, common pitfalls such as circular references, and use cases including shared configuration and database connection pools. ### Source excerpt Introduction: Welcome to Episode 6 of the Fearless Concurrency in Rust series! In this episode, we explore the powerful concept of ARC (Atomic Reference Counting) and its critical role in managing shared resources in multithreaded Rust programs. By leveraging ARC, developers can safely share ownership of data across threads without relying on a traditional garbage collector, enabling efficient, flexible, and scalable concurrency. What is ARC?: Understanding Atomic Reference Counting as a lightweight, manual garbage collection system. ## Kotlin var with Read-Only Collections vs. val with Mutable Collections DevFeed: [Kotlin var with Read-Only Collections vs. val with Mutable Collections]() Original publisher: [Read original article]() Published: 2024-06-03T00:00:00Z Content type: tutorial Language: en Sources: [Kt. Academy]() Topics: [Kotlin](), [Collections]() Tags: [atomic](), [bugs](), [collections](), [kotlin](), [memory](), [stateflow](), [workshop-learning-programming]() ### AI overview This article compares Kotlin var properties holding read-only collections with val properties holding mutable collections. It explains trade-offs involving copying costs, observability, defensive copies, and thread safety, concluding that the preferable choice depends on how the state is accessed and modified. ### Source excerpt Time to answer the question: var/readonly vs val/mutable. Which one should you use? ## 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 ## How Thumbtack structures their design system DevFeed: [How Thumbtack structures their design system]() Original publisher: [Read original article]() Author: Daniel O'Connor Published: 2023-07-13T00:00:00Z Content type: article Language: en Sources: [Figma Blog]() Topics: [Front end](), [Web Development](), [CSS](), [Software]() Tags: [architecture](), [atomic](), [component](), [components](), [css](), [design](), [design-systems](), [developers](), [efficiency](), [productivity](), [tokens](), [ui](), [web]() ### AI overview The article explains how Thumbtack organizes its Thumbprint design system into three layers: design tokens, an atomic CSS library, and reusable UI components. This layered architecture supports flexibility, efficiency, accessibility, and developer productivity across web and native clients. ### Source excerpt Staff Software Engineer Daniel O'Connor peels back the layers of the home service platform's design system, Thumbprint, to show how they built it for flexibility and efficiency. ## Ultimate Go: Advanced Engineering Episode 5 DevFeed: [Ultimate Go: Advanced Engineering Episode 5]() Original publisher: [Read original article]() Published: 2022-12-16T00:00:00Z Content type: tutorial Language: en Sources: [William Kennedy]() Topics: [Blockchain](), [Databases](), [Replication]() Tags: [atomic](), [consensus](), [consensus-algorithm](), [cryptographically-auditable](), [database](), [distributed](), [engineering](), [go-blockchain](), [golang-blockchain](), [poa](), [pos](), [pow](), [proof-of-authority](), [proof-of-work]() ### AI overview This video explains how to use blockchain concepts to design a distributed, auditable, synchronized, and scalable database for a dependency manager. It focuses on atomic writes, consensus, and a proof-of-work algorithm, while also discussing the inefficiency of proof of work and the emergence of proof of stake and proof of authority. ### Source excerpt Introduction In case you missed episode 4, Bill attempted to integrate current database sharing solutions to solve the "database ownership" problem his dependency manager faces. He tried providing copies of the database, implementing a load balancer and replication. While performing these experiments, Bill identified the qualities his dependency manager's database needs to have for users to trust it. He closed episode 4 by stating that his dependency manager needs a database that is distributed, cryptographically auditable, synchronized and scalable. By implementing this Bill hoped to provide greater transparency for his dependency manager. ## Atomic Commitment: The Unscalability Protocol DevFeed: [Atomic Commitment: The Unscalability Protocol]() Original publisher: [Read original article]() Author: Marc Brooker Published: 2022-10-04T00:00:00Z Content type: opinion Language: en Sources: [Marc Brooker's Blog](), [Marc Brooker's Blog]() Topics: [Transactions](), [Protocol (disambiguation)](), [Scalability](), [Database](), [Routing (disambiguation)](), [Architecture & Design](), [Computer science](), [data](), [dataset]() Tags: [atomic](), [complexity](), [database](), [routing](), [scalability](), [speed](), [transactions]() ### AI overview The article explains why atomic commitment can limit scalability in sharded databases. It contrasts single-row operations, which can be routed to individual shards, with distributed transactions that may require atomic writes across multiple machines. Using two-phase commit as the classic solution, it shows that throughput depends on the mean number of shards visited by each transaction: single-shard transactions can scale, while transactions spanning both shards provide no capacity increase. ### Source excerpt Atomic Commitment: The Unscalability Protocol 2PC is my enemy. Let's consider a single database system, running on one box, good for 500 requests per second. ┌───────────────────┐ │ Database │ │(good for 500 rps) │ └───────────────────┘ What if we want to access that data more often than 500 times a second? If by access we mean read, we have a lot of options. If be access, we mean write or even perform arbitrary transactions on, we're in a trickier situation. Tricky problems aside, we forge ahead by splitting our dataset into two shards: ┌───────────────────┐ ┌───────────────────┐ │ Database shard 1 │ │ Database shard 2 │ │(good for 500 rps) │ │(good for 500 rps) │ └───────────────────┘ └───────────────────┘ If we're just doing single row reads and writes, we're most of the way there. We just need to add a routing layer that can decide which shard to send each access to, and we're done1: ┌────────────┐ │ Router │ └────────────┘ ┬ ┌─────────┴───────────┐ ▼ ▼ ┌───────────────────┐ ┌───────────────────┐ │ Database shard 1 │ │ Database shard 2 │ │(good for 500 rps) │ │(good for 500 rps) │ └───────────────────┘ └───────────────────┘ But what if we have transactions? To make the complexity reasonable, and speed us on our journey, let's define a transaction as an operation that does writes to multiple rows, based on some condition, atomically. By atomically we mean that either all the writes happen or none of them do. By based on some condition we mean the transactions can express ideas like "reduce my bank balance by R10 as long as it's over R10 already". But how do we ensure atomicity across multiple machines? This is a classic computer science problem called Atomic Commitment. The classic solution to this classic problem is Two-phase commit, maybe the most famous of all distributed protocols. There's a lot we could say about atomic commitment, or even just about two-phase commit. In this post, I'm going to focus on just one aspect: atomic commitment has weird scaling be ## 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 ## Introducing Atomic Counters and Batch Sets for Serverless Data DevFeed: [Introducing Atomic Counters and Batch Sets for Serverless Data]() Original publisher: [Read original article]() Author: Jeremy Daly Published: 2022-03-08T00:00:00Z Content type: release Language: en Sources: [Serverless Blog]() Topics: [data](), [Serverless]() Tags: [announce](), [applications](), [atomic](), [aws](), [aws-lambda](), [batch](), [cloud](), [cloud-computing](), [data](), [faas](), [function-as-a-service](), [infrastructure-as-code](), [news](), [serverless](), [serverless-architecture](), [serverless-framework]() ### AI overview The article announces atomic counters and batch set operations for Serverless Data, expanding capabilities for building modern cloud applications. ### Source excerpt We're happy to announce the addition of atomic counters and batch set operations, giving users even more capabilities to rapidly build modern applications in the cloud. ## Rust atomics on x86: How and why DevFeed: [Rust atomics on x86: How and why]() Original publisher: [Read original article]() Author: Graham King Published: 2022-01-30T23:18:06Z Content type: article Language: en Sources: [Graham King]() Topics: [Rust](), [x86](), [ordering]() Tags: [assembly](), [atomic](), [atomics](), [ordering](), [rust](), [software](), [x86]() ### AI overview This article examines how Rust atomic memory orderings compile on x86. It finds that load and store operations generally produce the same instructions across orderings, while sequential consistency adds a full memory barrier. Read-modify-write operations also generally use the same instructions, though compiler reordering remains an important caveat. ### Source excerpt On x86 it doesn't really matter what sync::atomic::Ordering you choose. ## 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 ## EF-Supported Teams: Research & Development Update DevFeed: [EF-Supported Teams: Research & Development Update]() Original publisher: [Read original article]() Author: Ethereum Foundation Published: 2021-04-26T00:00:00Z Content type: article Language: en Sources: [Ethereum Foundation Blog]() Topics: [Development](), [Ethereum](), [Network](), [Transactions]() Tags: [atomic](), [audit](), [development](), [ecdsa](), [ethereum](), [graph](), [interface](), [network](), [organizational](), [research](), [research-development](), [smart-contract](), [transactions](), [update](), [upgrades]() ### AI overview This Ethereum Foundation update reports progress from several supported research and development teams. It covers projects including Zkopru, Hubble, and MACI, with updates on audits, rollups, throughput, smart-contract wallets, privacy-preserving peer search, and voting features. ### Source excerpt Friends, The year ahead will be filled with upgrades and big ideas from across the Ethereum ecosystem. Since our last Supported Teams post (which followed the launch of the beacon chain), the network has seen 3.8+ million Ether staked, and 120K+ active validators online across multiple clients. In... ## C++ Concurrency Model on x86 for Dummies DevFeed: [C++ Concurrency Model on x86 for Dummies]() Original publisher: [Read original article]() Author: Viktor Leis (noreply@blogger.com) Published: 2020-10-30T16:17:00Z Content type: tutorial Language: en Sources: [Database Architects]() Topics: [C++](), [Concurrency](), [x86](), [Compiler](), [Data structures]() Tags: [atomic](), [c-plus-plus](), [code](), [compiler](), [concurrency](), [data-structures](), [x86]() ### AI overview This tutorial explains a practical subset of the C++11 memory model for writing high-performance concurrent code on x86. It emphasizes using std::atomic, choosing memory orders, and avoiding undefined behavior from data races, while noting that the simplified approach may be less efficient on non-x86 platforms such as ARM. ### Source excerpt Since C++11, multi-threaded C++ code has been governed by a rigorous memory model. The model allows implementing concurrent code such as low-level synchronization primitives or lock-free data structures in a portable fashion. To use the memory model, programmers need to do two things: First, they have to use the std::atomic type for concurrently-accessed memory locations. Second, each atomic operation requires a memory order argument with six options determining the concurrency semantics in terms of which re-orderings are allowed. (Some operations even allow specifying two memory orders!) While there are a number of attempts to describe the model, I always found the full semantics very hard to understand and consequently concurrent code hard to write and reason about. And since we are talking about low-level concurrent code here, making a mistake (like picking the wrong memory order) can lead to disastrous consequences. Luckily, at least on x86, a small subset of the full C++11 memory model is sufficient. In this post, I'll present such a subset that is sufficient to write high-performance concurrent code on x86. This simplification has the advantage that the resulting code is much more likely to be correct, without leaving any performance on the table. (On non-x86 platforms like ARM, code written based on this simplified model will still be correct, but might potentially be slightly slower than necessary.) There are only six things one needs to know to write high-performance concurrent code on x86. 1. Data races are undefined If a data race occurs in C++, the behavior of the program is undefined. Let's unpack that statement. A data race can be defined as two or more threads accessing the same memory location with at least one of the accesses being a write. By default (i.e., without using std::atomic), the compiler may assume that no other thread is concurrently modifying memory. This allows the compiler to optimize the code, for example by reordering or optimizing ## Red/System: New Features DevFeed: [Red/System: New Features]() Original publisher: [Read original article]() Author: Nenad Rakocevic (noreply@blogger.com) Published: 2020-08-20T10:54:00Z Content type: release Language: en Sources: [Red]() Topics: [Red](), [Code]() Tags: [arrays](), [atomic](), [bugfixes](), [compilation](), [exceptions](), [features](), [floating-point](), [fpu](), [ia-32](), [literal-arrays](), [math](), [new-features](), [pointers](), [red-system](), [runtime-errors](), [vfp]() ### AI overview An overview of recent Red/System features, including subroutines, atomic and stack intrinsics, FPU status access, and changes to literal arrays. ### Source excerpt In the past months, many new features were added to Red/System, the low-level dialect embedded in Red. Here is a sum up if you missed them. Subroutines During the work on the low-level parts of the new Red lexer, the need arised for intra-function factorization abilities to keep the lexer code as DRY as possible. Subroutines were introduced to solve that. They act as the GOSUB directive from Basic language. They are defined as a separate block of code inside a function's body and are called like regular functions (but without any arguments). So they are much lighter and faster than real function calls and require just one slot of stack space to store the return address. The declaration syntax is straightforward: : [] : subroutine's name (local variable). : subroutine's code (regular R/S code). To define a subroutine, you need to declare a local variable with the subroutine! datatype, then set that variable to a block of code. You can then invoke the subroutine by calling its name from anywhere in the function body (but after the subroutine own definition). Here is a first example of a fictive function processing I/O events: process: func [buf [byte-ptr!] event [integer!] return: [integer!] /local log do-error [subroutine!] ][ log: [print-line [">>" tab e "<<"]] do-error: [print-line ["** Error:" e] return 1] switch event [ EVT_OPEN [e: "OPEN" log unless connect buf [do-error]] EVT_READ [e: "READ" log unless receive buf [do-error]] EVT_WRITE [e: "WRITE" log unless send buf [do-error]] EVT_CLOSE [e: "CLOSE" log unless close buf [do-error]] default [e: "" do-error] ] 0 ] This second example is more complete. It shows how subroutines can be combined and how values can be returned from a subroutine: #enum modes! [ CONV_UPPER CONV_LOWER CONV_INVERT ] convert: func [mode [modes!] text [c-string!] return: [c-string!] /local lower? upper? alpha? do-conv [subroutine!] delta [integer!] s [c-string!] c [byte!] ][ lower?: [all [#"a" <= c c <= # ## Atomic Deployments Without Tears DevFeed: [Atomic Deployments Without Tears]() Original publisher: [Read original article]() Author: andrew@nystudio107.com (Andrew Welch) Published: 2020-06-30T04:00:00Z Content type: tutorial Language: en Sources: [nystudio107 | Articles on modern web development.]() Topics: [CI/CD](), [Deployment](), [Git](), [Content Management System](), [Development]() Tags: [amazon-s3](), [atomic](), [automatically](), [changes](), [continuous](), [continuous-integration](), [deploy](), [deployments](), [downtime](), [git](), [how-to](), [insights](), [integration](), [learn](), [safely](), [tools](), [using](), [website](), [zero]() ### AI overview This tutorial explains how to use Continuous Integration tools to perform atomic, zero-downtime deployments for Craft CMS websites. It covers a workflow based on local development, a cloud Git repository, and automated deployment to production or staging servers. ### Source excerpt Learn how to use atomic deployments to automatically and safely deploy changes to your website with zero downtime using Continuous Integration (CI) tools ## On Fair & Scalable Locks DevFeed: [On Fair & Scalable Locks]() Original publisher: [Read original article]() Author: Alimate Published: 2020-03-07T00:00:00Z Content type: tutorial Language: en Sources: [Ali Dehghan - Kemikit]() Topics: [Concurrency](), [Optimization](), [Benchmark](), [cpu]() Tags: [atomic](), [benchmark](), [cpu](), [latency](), [locks](), [optimization](), [threads]() ### AI overview This tutorial explains test-and-set (TAS) locks and test-test-and-set (TTAS) locks, then compares them with a multithreaded benchmark. The supplied text reports that TTAS has better throughput and lower-jitter latency than TAS in that benchmark. ### Source excerpt Let's implement a fair and highly scalable lock! ## The July Galileo Outage: What happened and why DevFeed: [The July Galileo Outage: What happened and why]() Original publisher: [Read original article]() Published: 2019-11-07T08:48:53Z Content type: article Language: en Sources: [Bert Hubert's writings]() Topics: [navigation](), [systems]() Tags: [atomic](), [clocks](), [gnss](), [orbit](), [outage](), [performance](), [precision](), [systems](), [technical-article](), [timing]() ### AI overview An excerpt examines the July Galileo outage, explaining how GNSS operation depends on accurately modeling satellite orbits and atomic clocks and distinguishing errors in satellite, clock, and ground timing data. ### Source excerpt By bert hubert / bert@hubertnet.nl This post is an excerpt of a far longer post on Galileo, its structures and the cause of the outage. Here we'll only focus on the outage - the potential underlying reasons behind it are described in the full article. Since the week-long outage in July I've been fascinated by Galileo and, together with a wonderful crew of developers, experts and receiver operators, have learned so much about what I now know are called 'Global Navigation Satellite Systems' or GNSS. [Next page]()