# synchronization Published articles for synchronization. This is one page of public article previews, not the complete archive. Follow Next page to continue. Summaries are not the original full articles. ## Calendar API: Local Calendars, Cloud Sync, and Conflict Handling DevFeed: [Calendar API: Local Calendars, Cloud Sync, and Conflict Handling]() Original publisher: [Read original article]() Author: Shai Almog Published: 2026-07-25T00:00:00Z Content type: release Language: en Sources: [CodeName One]() Topics: [API](), [cross-platform](), [Concurrency](), [Cloud](), [Google Calendar](), [Android](), [iOS](), [macOS](), [Microsoft](), [JavaScript](), [HTTP](), [OAuth]() Tags: [android](), [api](), [apis](), [apple](), [backend](), [cloud](), [concurrency](), [cross-platform](), [google](), [http](), [ios](), [javascript](), [macos](), [oauth](), [offline](), [storage](), [sync](), [synchronization](), [work]() ### AI overview The article introduces a cross-platform calendar API that unifies local calendars and cloud providers through a capability-based model. It covers events, tasks, recurrence, time zones, offline mutations, optimistic concurrency, provider synchronization, and conflict handling. ### Source excerpt The new calendar API handles local calendars, cloud providers, recurrence, conflicts, and offline changes through one capability-based model. ## Handling concurrency on the Web with Web Locks API DevFeed: [Handling concurrency on the Web with Web Locks API]() Original publisher: [Read original article]() Author: Cesar Contreras Published: 2026-07-14T15:36:00Z Content type: tutorial Language: en Sources: [OLX]() Topics: [Concurrency](), [Web](), [API](), [Web Development](), [web applications](), [browser]() Tags: [api](), [browser](), [concurrency](), [locks](), [react](), [resumable-file-upload](), [synchronization](), [web](), [web-applications](), [web-development]() ### AI overview This article explains concurrency on the web through the Web Locks API. It describes an OLX upload scenario involving files up to 20GB, where uploads should resume after a browser or tab is reopened without requiring the user to remain in the web app. It identifies multiple tabs resuming the same upload simultaneously as a cause of duplicate uploads, wasted bandwidth, extra processing costs, and unpredictable progress. ### Source excerpt Image by the_iop from Pixabay Concurrency in programming is the ability to manage and execute multiple tasks or processes at the same time (or appear to), allowing programs to remain responsive and efficient. Think of it like a chef in a busy kitchen: they're not cooking every dish from start to finish sequentially, but instead chopping vegetables while one pan simmers and another bakes; juggling progress on several tasks concurrently. I'm a frontend engineer at OLX working mostly with React and NextJs, but I also came from a background in which I worked primarily in concurrent programs with Java. Creating multi-threaded applications can be a pain, dealing with locks, semaphores... and my favorite... deadlocks (very scary in large codebases). Once I transitioned fully to Web development, I never imagined I would have to deal with scenarios like this, and then here I am writing my first article about it. Web development has turned into a very powerful ecosystem, from the previous era where the web was only about flashy animations using HTML marquee (a bit of sarcasm here 😆), dominated by JQuery, to a really powerful environment where you can use Workers, 2D and 3D animations with WebGL and Canvas, offline capabilities with Service Workers, and the list continues. This is evidence that the Web can now face really complex challenges, and it's just a matter of time before you have to face similar ones. The problem Recently, at OLX, we faced the challenge of working with large file size uploads. Providing the best user experience is tricky when it comes to handling uploads, and most of the real use cases out there require the user to stay in the web app until the upload completes, but we didn't want that. Since we are working with large file sizes (up to 20GB), we want the user to be free and do other stuff while this is uploading, so if the user closes and opens the browser or tab, the upload should continue with no manual intervention. For this, we had to provide a mechani ## A 15-Second Health Check for Your Heroku Connect Data Pipeline DevFeed: [A 15-Second Health Check for Your Heroku Connect Data Pipeline]() Original publisher: [Read original article]() Author: Nick Prey Published: 2026-06-24T15:35:14Z Content type: tutorial Language: en Sources: [Heroku]() Topics: [Heroku](), [Command-line interface](), [Data Management](), [SQL](), [Databases]() Tags: [cli](), [data-pipeline](), [engineering](), [heroku](), [heroku-connect](), [migrations](), [salesforce](), [schema](), [synchronization](), [troubleshooting]() ### AI overview This tutorial explains how the Heroku Connect CLI plugin's diagnostic command checks connection health, schema alignment, and field configurations in a Salesforce-to-Heroku Postgres data pipeline. It highlights how the command can expose configuration mismatches and provide actionable warnings before schema updates or migrations. ### Source excerpt Heroku Connect is a fully managed, bidirectional data sync service between Salesforce and Heroku Postgres that lets developers read and write Salesforce data using standard SQL. The sync is straightforward to set up and operates smoothly in the background, but when a field does not update as expected or data seems to lag, you do not need to guess what went wrong. The post A 15-Second Health Check for Your Heroku Connect Data Pipeline appeared first on Heroku. ## How clock drift and network latency affect distributed database writes, and how Spanner uses TrueTime DevFeed: [How clock drift and network latency affect distributed database writes, and how Spanner uses TrueTime]() Original publisher: [Read original article]() Author: hello@ankit-rana.com Published: 2026-05-17T00:00:00Z Content type: article Language: en Sources: [Ankit Rana | Mechanical Sympathy]() Topics: [distributed-systems](), [Databases](), [Network](), [Latency](), [Hardware](), [Google]() Tags: [clocks](), [consistency](), [data](), [databases](), [distributed-systems](), [google](), [gps](), [hardware](), [latency](), [network](), [ntp](), [spanner](), [synchronization](), [truetime]() ### AI overview The article explains how quartz-clock drift and variable network latency limit NTP synchronization across servers. It describes how clock skew can cause last-write-wins conflict resolution to silently discard a newer database write, and presents Google Spanner's use of GPS, atomic clocks, and TrueTime uncertainty intervals as a mitigation. ### Source excerpt Server clocks come from quartz crystals that drift with temperature, and NTP cannot fully correct them because you cannot measure absolute time over a variable-latency network. Under last-write-wins, a node whose clock runs 10 ms fast can silently discard a newer write from a node that is behind: no error, normal logs, lost user data. Spanner solves it with GPS and atomic clocks, where TrueTime returns an uncertainty interval and the commit waits it out. ## 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 ## Waiting for PostgreSQL 19 - Sequence synchronization in logical replication. DevFeed: [Waiting for PostgreSQL 19 - Sequence synchronization in logical replication.]() Original publisher: [Read original article]() Author: depesz Published: 2025-11-11T12:24:23Z Content type: tutorial Language: en Sources: [select \* from depesz;]() Topics: [PostgreSQL](), [Replication](), [Sequences]() Tags: [benchmark](), [logical](), [pg19](), [postgresql](), [psql](), [publications](), [replication](), [sequence](), [sequences](), [synchronization](), [uncategorized](), [upgrade](), [upgrades](), [waiting]() ### AI overview This article demonstrates PostgreSQL 19's planned sequence synchronization for logical replication. It sets up source and destination databases, tests sequence synchronization, finds that resynchronization must be manually invoked, and reports that synchronizing 10,000 sequences took about one second in the author's test. ### Source excerpt First, on 9th of October 2025, Amit Kapila committed patch: Add "ALL SEQUENCES" support to publications. This patch adds support for the ALL SEQUENCES clause in publications, enabling synchronization/replication of all sequences that is useful for upgrades. Publications can now include all sequences via FOR ALL SEQUENCES. psql enhancements: \d shows publications for ... Continue reading "Waiting for PostgreSQL 19 - Sequence synchronization in logical replication." ## Corrosion DevFeed: [Corrosion]() Original publisher: [Read original article]() Published: 2025-10-22T00:00:00Z Content type: article Language: en Sources: [The Fly Blog]() Topics: [distributed-systems](), [Concurrent Programming](), [Deadlock](), [Rust](), [Network](), [Orchestration](), [fly](), [fly.io]() Tags: [cdn](), [close-to-users](), [deadlock](), [deploy-app-servers](), [distributed-system](), [docker](), [docker-containers](), [elixir](), [fly](), [fly-io](), [heroku-alternative](), [heroku-competitor](), [hosting](), [i](), [networking](), [outage](), [pipelines](), [postgresql-clusters](), [routing](), [rust](), [servers](), [synchronization]() ### AI overview This article introduces Corrosion, Fly.io's open-source distributed state synchronization and service discovery system. It explains how Fly.io propagates workload and routing state across globally distributed servers and edge proxies, and recounts a severe outage caused by a Rust concurrency bug that triggered a contagious deadlock. The article also describes Fly.io's decentralized orchestration model, in which individual servers are authoritative for their workloads instead of relying on a centralized database. ### Source excerpt Fly.io transmogrifies Docker containers into Fly Machines: micro-VMs running on our own hardware all over the world. The hardest part of running this platform isn't managing the servers, and it isn't operating the network; it's gluing those two things together. Several times a second, as customer CI/CD pipelines tear up or bring down Fly Machines, our state synchronization system blasts updates across our internal mesh, so that edge proxies from Tokyo to Amsterdam can keep the accurate routing table that allows them to route requests for applications to the nearest customer instances. On September 1, 2024, at 3:30PM EST, a new Fly Machine came up with a new "virtual service" configuration option a developer had just shipped. Within a few seconds every proxy in our fleet had locked up hard. It was the worst outage we've experienced: a period during which no end-user requests could reach our customer apps at all. Distributed systems are blast amplifiers. By propagating data across a network, they also propagate bugs in the systems that depend on that data. In the case of Corrosion, our state distribution system, those bugs propagate quickly. The proxy code that handled that Corrosion update had succumbed to a notorious Rust concurrency footgun: an if let expression over an RWLock assumed (reasonably, but incorrectly) in its else branch that the lock had been released. Instant and virulently contagious deadlock. A lesson we've learned the hard way: never trust a distributed system without an interesting failure story. If a distributed system hasn't ruined a weekend or kept you up overnight, you don't understand it yet. Which is why that's how we're introducing Corrosion, an unconventional service discovery system we built for our platform and open sourced. Our Face-Seeking Rake State synchronization is the hardest problem in running a platform like ours. So why build a risky new distributed system for it? Because no matter what we try, that rake is waiting for our foot ## Parallel Compression Revamp: Dramatically Reduced CPU Overhead DevFeed: [Parallel Compression Revamp: Dramatically Reduced CPU Overhead]() Original publisher: [Read original article]() Author: Peter Dillinger Published: 2025-10-08T00:00:00Z Content type: release Language: en Sources: [RocksDB]() Topics: [Compression](), [rocksdb](), [Concurrency](), [Concurrent Programming](), [Pull Request]() Tags: [architecture](), [blog](), [compression](), [lock-free](), [parallel](), [pull-request](), [rocksdb](), [storage](), [synchronization]() ### AI overview RocksDB 10.7 is expected to include a reimplementation of parallel compression that reduces CPU overhead by up to 65% while maintaining or improving throughput for compression-heavy workloads. The redesign uses a ring buffer, work-stealing-style thread participation, automatic thread scaling, and primarily atomic, lock-free synchronization. ### Source excerpt The upcoming RocksDB 10.7 release includes a major revamp of parallel compression that dramatically reduces the feature's CPU overhead by up to 65% while maintaining or improving throughput for compression-heavy workloads. We expect this to broaden the set of workloads that could benefit from parallel compression, especially for bulk SST generation and remote compaction use cases that are less sensitive to CPU responsiveness. Background Parallel compression in RocksDB (CompressionOptions::parallel_threads > 1) allows multiple threads to compress different blocks simultaneously during SST file generation, which can significantly improve compaction throughput for workloads where compression is a bottleneck. However, the original implementation had substantial CPU overhead that often outweighed the benefits, limiting its practical adoption. What's New: A Complete Reimplementation The parallel compression framework has been completely rewritten from the ground up in pull request #13910 to address the core inefficiencies: Ring Buffer Architecture Instead of separate compression and write queues with complex thread coordination, the new implementation uses a ring buffer of blocks-in-progress that enables efficient work distribution across threads. This bounds working memory while enabling high throughput with minimal cross-thread synchronization. Work-Stealing Design Previously, the calling thread could only generate uncompressed blocks, dedicated compression threads could only compress, and a writer thread could only write the SST file to storage. Now, all threads can participate in compression work in a quasi-work-stealing manner, dramatically reducing the need for threads to block waiting for work. While only one thread (the calling thread or "emit thread") can generate uncompressed SST blocks in the new implementation, feeding compression work to other threads and itself, all other threads are compatible with writing compressed blocks to storage. Auto-Scaling Thread M ## SwiNOG 40: Deploying Precision Time Protocol across WAN DevFeed: [SwiNOG 40: Deploying Precision Time Protocol across WAN]() Original publisher: [Read original article]() Published: 2025-09-23T05:33:00Z Content type: article Language: en Sources: [ipSpace.net blog]() Topics: [Network](), [Protocol (disambiguation)]() Tags: [infrastructure](), [network](), [precision](), [protocol](), [ptp](), [synchronization](), [time](), [wide](), [worth-reading]() ### AI overview The article discusses deploying Precision Time Protocol across a country-wide WAN to achieve nanosecond-level synchronization between cities. It states that this requires dedicated infrastructure and points to a SwiNOG 40 presentation by Oliver Ettlin for more details. ### Source excerpt Is it possible to deploy Precision Time Protocol across a country-wide WAN network and reach nanosecond-level synchronization between cities? It's definitely not trivial and only works over dedicated infrastructure; for more details, watch the PTP in WANs (video) presentation Oliver Ettlin had at SwiNOG 40. ## Underrust: What is the cost of Mutex, RwLock and AtomicPtr? DevFeed: [Underrust: What is the cost of Mutex, RwLock and AtomicPtr?]() Original publisher: [Read original article]() Author: Graham King Published: 2025-05-05T20:05:00Z Content type: tutorial Language: en Sources: [Graham King]() Topics: [Rust](), [Concurrent Programming](), [x86](), [cpu](), [Assembly]() Tags: [assembly](), [concurrent](), [cpu](), [cycles](), [locking](), [performance](), [rust](), [software](), [synchronization](), [underrust]() ### AI overview A Rust-focused analysis uses assembly output to examine the cost of Mutex, RwLock, and atomic operations for many concurrent readers and an occasional writer. It scopes the discussion to Linux and x86, noting that the fast-path operations discussed are roughly in the range of 20 to 30 CPU cycles. ### Source excerpt With many concurrent readers and a single occasional writer, which mutual exclusion primitive should you use? Let's look at the assembly to find out. ## Benchmarking the Performance of Java and Kotlin Reflection DevFeed: [Benchmarking the Performance of Java and Kotlin Reflection]() Original publisher: [Read original article]() Published: 2024-12-16T00:00:00Z Content type: article Language: en Sources: [Kt. Academy]() Topics: [Benchmark](), [Java](), [Kotlin](), [kotlin compiler]() Tags: [benchmark](), [benchmarks](), [java](), [kotlin](), [kotlin-compiler](), [logging](), [performance](), [synchronization](), [workshop-learning-programming]() ### AI overview This article benchmarks regular function calls, Java reflection, and Kotlin reflection. It finds that reflection is much slower than regular calls, Java reflection is slightly faster than Kotlin reflection in the measured test, and reflection has a comparable cost to synchronization while being faster than logging. ### Source excerpt Let's benchmark reflection and see how it affects the performance of your code. ## 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. ## Zed Adds Remote Development Over SSH DevFeed: [Zed Adds Remote Development Over SSH]() Original publisher: [Read original article]() Author: Conrad Irwin Published: 2024-10-30T00:00:00Z Content type: article Language: en Sources: [Zed Industries - Blog]() Topics: [remote-development](), [ssh](), [Development]() Tags: [architecture](), [cloud](), [collaboration](), [development](), [linux](), [machine](), [projects](), [protocol](), [rebuilds](), [remote](), [remote-development](), [server](), [ssh](), [synchronization](), [tests]() ### AI overview Zed adds remote development over SSH, keeping the user interface local while running language servers, tasks, and terminals on the remote machine. The article explains connection maintenance, remote server installation and compatibility, reconnection behavior, local backups, and collaboration support. ### Source excerpt Zed can now be used to edit over SSH. ## 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. ## 4 Software Design Principles I Learned the Hard Way DevFeed: [4 Software Design Principles I Learned the Hard Way]() Original publisher: [Read original article]() Author: Engineer's Codex Published: 2024-04-22T19:03:53Z Content type: article Language: en Sources: [Engineer's Codex]() Topics: [Software Engineering](), [Architecture & Design](), [Software](), [Code]() Tags: [code](), [design](), [software-design](), [software-engineering](), [source-of-truth](), [synchronization]() ### AI overview An experienced software engineer shares design principles drawn from building and launching a large service. The article argues for maintaining one source of truth, deriving values instead of storing duplicate state when practical, and selectively repeating code rather than forcing unsuitable abstractions. It emphasizes that these principles require context and tradeoffs. ### Source excerpt If there's two sources of truth, one is probably wrong. And yes, please repeat yourself. ## Ep. 1: Defending Against Memory Breaches: Exploring Rust and Go's Safety Mechanisms DevFeed: [Ep. 1: Defending Against Memory Breaches: Exploring Rust and Go's Safety Mechanisms]() Original publisher: [Read original article]() Published: 2024-04-15T00:00:00Z Content type: tutorial Language: en Sources: [William Kennedy]() Topics: [Rust](), [Memory Safety](), [Go Language](), [Programming](), [Security]() Tags: [c](), [concurrent](), [concurrent-programming](), [go](), [golang](), [languages](), [memory-breaches](), [memory-management](), [memory-safety](), [rust](), [safety](), [safety-mechanism](), [security](), [synchronization]() ### AI overview This introductory video examines memory safety in programming languages, focusing on Rust and comparing its approach with Go, Java, and C. It discusses buffer overflows, memory leaks, data races, static analysis, checked arithmetic, and the trade-offs between safety and performance. ### Source excerpt Introduction: Rust's memory safety features are advantageous to Rust developers because they: Ensure robust protection against buffer overflows and underflows, enhancing the reliability and security of software. Empower developers to manage type coercion effectively, promoting code reliability and safety while facilitating safe type conversions. Provide confidence in writing concurrent code by enforcing strict mutability rules and synchronization, thereby preventing data race issues and ensuring code correctness and efficiency. With these memory safety features deeply integrated into Rust's design, developers can build more reliable, secure, and efficient software, spanning various aspects of memory management, type handling, and concurrent programming paradigms. ## Oxidizing OCaml: Data Race Freedom DevFeed: [Oxidizing OCaml: Data Race Freedom]() Original publisher: [Read original article]() Author: Max Slater Published: 2023-09-01T00:00:00Z Content type: article Language: en Sources: [Jane Street]() Topics: [OCaml](), [Concurrency](), [data](), [async/await](), [Rust]() Tags: [async](), [atomics](), [await](), [code](), [concurrency](), [data](), [ocaml](), [rust](), [synchronization]() ### AI overview This final post in a series explains how Jane Street uses OCaml modes and capsules to design a statically data-race-free API for multicore OCaml. It discusses shared-memory parallelism, the risks of mutable data races, and approaches for safely handling shared mutability across domains. ### Source excerpt OCaml with Jane Street extensions is available from our public opam repo. Only a slice of the features described in this series are currently implemented. ## Objects in Kotlin DevFeed: [Objects in Kotlin]() Original publisher: [Read original article]() Published: 2023-07-17T00:01:00Z Content type: tutorial Language: en Sources: [Kt. Academy]() Topics: [Kotlin](), [object](), [class](), [constructor](), [interfaces]() Tags: [class](), [constructor](), [interfaces](), [kotlin](), [object](), [synchronization](), [syntax](), [workshop-learning-programming]() ### AI overview This Kotlin tutorial explains how to create objects with object expressions and object declarations. It covers anonymous objects, inheritance and interface implementation, object scope, singleton behavior, and practical uses such as listeners and synchronization locks. ### Source excerpt What is object expression, object declaration and companion objects, and how we use them. ## Reasoning about asyncio.Semaphore DevFeed: [Reasoning about asyncio.Semaphore]() Original publisher: [Read original article]() Author: Guido van Rossum (noreply@blogger.com) Published: 2022-10-05T06:39:00Z Content type: article Language: en Sources: [Guido van Rossum]() Topics: [Concurrency](), [Concurrent Programming](), [await]() Tags: [await](), [fairness](), [implementing](), [performance](), [reasoning](), [semantics](), [synchronization]() ### AI overview The article explains asyncio synchronization primitives through a restaurant queuing analogy. It maps exclusive access and cancellation to a Lock, then explains why multiple concurrently seated guests require a Semaphore. It also discusses challenges involving fairness, correctness, semantics, and performance. ### Source excerpt In Silicon Valley is a very exclusive fast-food restaurant, which is always open. There is one table, where one guest at a time is served an absolutely fabulous hamburger. When you arrive, you wait in line until the table is available. Then the host takes you to the table and, this being America, you are asked a seemingly endless series of questions about how you would like your hamburger to be cooked and served. But today we're not talking about culinary delights. We're talking about the queuing system used by the restaurant. If you are lucky to arrive at the restaurant when the table is available and there are no other guests waiting, you are seated right away. Otherwise, the host gives you a buzzer (from an infinite stack of buzzers!) and you are free to roam the neighborhood until your buzzer goes off. It is the host's job to ensure that guests are seated in order of arrival. When it is your turn, the host will cause your buzzer go off and you make your way back to the restaurant, where you will be seated. If you change your mind, you can return the buzzer to the host, who will take it back without lifting an eyebrow. If your buzzer has already gone off, the host will buzz the next guest, if any. Guests are always polite and don't abscond with their buzzers. The host is always fair and doesn't seat another guest ahead of you even if you take your time making it back. The above description fits that of a Lock. A guest arriving corresponds to the acquire() call; leaving is a release() call. Changing your mind is like getting cancelled while waiting in acquire(). You can change your mind before or after your buzzer goes off, i.e., you can be cancelled before or after the lock has awakened your call (but before you return from acquire()). One day the restaurant expands, hiring extra sous-chefs and opening several new tables. There is still only one host, whose job is not really changed. However, since multiple guests can be seated concurrently, a Semaphore must now ## Effective Kotlin Item 1: Limit mutability DevFeed: [Effective Kotlin Item 1: Limit mutability]() Original publisher: [Read original article]() Published: 2022-09-28T00:00:00Z Content type: tutorial Language: en Sources: [Kt. Academy]() Topics: [Kotlin](), [Code](), [test]() Tags: [debug](), [kotlin](), [state-management](), [synchronization](), [test](), [workshop-learning-programming]() ### AI overview This Kotlin article explains why limiting mutability makes programs easier to understand, reason about, debug, synchronize, and test. It describes how mutable state can create dependencies, unintended side effects, additional possible states, and notification requirements when values change. ### Source excerpt Why it is so important to limit mutability, and how Kotlin supports it. ## Making unwinding through JIT-ed code scalable - The b-tree DevFeed: [Making unwinding through JIT-ed code scalable - The b-tree]() Original publisher: [Read original article]() Author: Thomas Neumann (noreply@blogger.com) Published: 2022-06-26T08:56:00Z Content type: article Language: en Sources: [Database Architects]() Topics: [Data structures](), [Concurrency](), [Concurrent Programming](), [Code]() Tags: [code](), [data-structure](), [implementation](), [memory](), [node](), [object](), [recursion](), [structure](), [synchronization]() ### AI overview This article explains the data-structure and infrastructure portions of a scalable unwinding system that uses a B-tree for fast lookup and data locality. It describes node organization, invariants, fence keys, helper functions, optimistic lock coupling, memory reclamation through a free list, and recursive destruction; insert, remove, and lookup operations are deferred to the next article. ### Source excerpt This article is part of the series about scalable unwinding that starts here. We use a b-tree because it offers fast lookup, good data locality, and a scalable implementation is reasonable easy when using optimistic lock coupling. Nevertheless a b-tree is a non-trivial data structure. To avoid having one huge article that includes all details of the b-tree, we just discuss the data structure themselves and some helper functions here, the insert/remove/lookup operations will be discussed in the next article. A b-tree partitions its elements by value. An inner node contains a sorted list of separator/child pairs, with the guarantee that the elements in the sub-tree rooted at the child pointer will be <= the separator. The leaf nodes contains sorted lists of (base, size, object) entries, where the object is responsible for unwinding entries between base and base+size. An b-tree maintains the invariants that 1) all nodes except the root are at least half full, and 2) a leaf nodes have the same distance to the root. This guarantees us logarithmic lookup costs. Note that we use fence-keys, i.e., the inner nodes have a separator for the right-most entries, too, which is not the case in all b-tree implementations: // The largest possible separator value static const uintptr_t max_separator = ~((uintptr_t) (0)); // Inner entry. The child tree contains all entries <= separator struct inner_entry { uintptr_t separator; struct btree_node *child; }; // Leaf entry. Stores an object entry struct leaf_entry { uintptr_t base, size; struct object *ob; }; // node types enum node_type { btree_node_inner, btree_node_leaf, btree_node_free }; // Node sizes. Chosen such that the result size is roughly 256 bytes #define max_fanout_inner 15 #define max_fanout_leaf 10 // A btree node struct btree_node { // The version lock used for optimistic lock coupling struct version_lock version_lock; // The number of entries unsigned entry_count; // The type enum node_type type; // The payload union { / ## 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. ## Blockchain In Go: Part II: Transaction Distribution and Synchronization DevFeed: [Blockchain In Go: Part II: Transaction Distribution and Synchronization]() Original publisher: [Read original article]() Published: 2022-03-08T00:00:00Z Content type: tutorial Language: en Sources: [William Kennedy]() Topics: [Blockchain](), [Transactions](), [Go Language](), [API](), [REST API](), [Concurrency](), [Cache](), [HTTP](), [JSON]() Tags: [api](), [blockchain](), [build-blockchain-from-scratch](), [cache](), [digital-wallet](), [distribution](), [ethereum](), [go](), [go-blockchain](), [golang-blockchain](), [http](), [implementation](), [json](), [mempool-blockchain](), [network](), [project](), [rest-api](), [series](), [synchronization](), [transactions]() ### AI overview This second article in a blockchain series explains how the Ardan blockchain distributes and synchronizes transactions between nodes. It describes submission through a wallet, storage in an in-memory mempool, signaling through a goroutine, and propagation to other nodes. It also introduces the HTTP-based REST API used for wallet and node communication. ### Source excerpt Introduction In the first post, I explained there were four aspects of a blockchain that this series would explore with a backing implementation provided by the Ardan blockchain project. Digital accounts with electronic signatures and verification Transaction distribution and synchronization between computers Redundant storage and consensus by different computers Detection of any fraud to past transactions The first post focused on how the Ardan blockchain provides support for digital accounts, signatures, and verification. In this second post, I will focus on transaction distribution and synchronization between different computers (blockchain nodes). [Next page]()