The most fundamental cause of thread safety issues is shared mutable state (e.g., class instance variables, module variables, or shared mutable objects). In environments with multiple execution contexts like fibers or threads, shared mutable state creates unpredictable execution paths.

Best Practices:

• Avoid sharing mutable state whenever possible.
• Prefer isolation, immutability, and pure functions.
• If shared state is necessary, use coordination primitives like Mutex or concurrent data structures, but be aware of deadlocks and contention.

class CurrencyConverter
	def initialize
		@exchange_rates = {} # Issue: Shared mutable state
	end
	
	def update_rate(currency, rate)
		# Issue: Multiple threads can modify @exchange_rates concurrently
		@exchange_rates[currency] = rate
	end
	
	def convert(amount, from_currency, to_currency)
		# Issue: If @exchange_rates is modified while this method runs, it can lead to incorrect conversions
		rate = @exchange_rates[from_currency] / @exchange_rates[to_currency]
		amount * rate
	end
end

Fibers and threads are both primitives for concurrent execution, but they differ in how they are scheduled:

Fibers

• Cooperative multitasking: Usually runs within a single thread.
• No preemption: A fiber must explicitly yield control. If a fiber executes a long-running task without yielding, it can cause latency issues for other fibers.
• Explicit yield points: Control is yielded during I/O, Fiber.yield, sleep, etc.
• Lightweight: Context switching is fast because it happens in user-space.
• Limited parallelism: Parallelism is limited unless blocking operations are offloaded to a worker pool.

Threads

• Preemptive multitasking: Managed by the operating system and the Ruby thread scheduler.
• Preemption: The interpreter can interrupt a thread at almost any point.
• Expensive: Context switching has higher overhead due to OS involvement and interpreter contention.
• Limited parallelism: Subject to the Ruby GVL (Global VM Lock) unless using rb_nogvl capable operations.

When writing concurrent Ruby code using fibers or threads, follow these fundamental principles to prevent data corruption and race conditions:

• Prioritize Data Integrity: Preventing data corruption is the most critical goal.
• Default to Isolation: Avoid sharing mutable state. Prefer using pure functions, immutable objects, and dependency injection.
• Assume Concurrency: Write code assuming it will be executed concurrently by multiple fibers, threads, or processes.
• Assume Context Switching: Assume code may context switch at any time. Context switches occur most frequently during:
  • I/O operations: Network calls, file I/O, database queries, etc.
  • Explicit points: Fiber.yield, sleep, waiting on child processes, DNS queries, and signal handling (interrupts).
• Beware of C Extensions: Native extensions (C/Rust) can block the fiber scheduler entirely. If a native operation is blocking, consider offloading it to a thread pool to avoid stalling the event loop.

When designing concurrent systems, choose a safety model based on the level of coordination required. The hierarchy from safest to most complex is:

1. No shared state (Ideal): Isolate state to each thread, fiber, or request. No coordination or synchronization is needed.
2. Immutable shared state (Very good): Share data that does not change after creation, such as constants or frozen objects.
3. Synchronized mutable state (Only when unavoidable): Share mutable state using robust synchronization mechanisms.

Synchronization Strategies

If you must use synchronized mutable state, choose the appropriate level of granularity:

• Lock-free structures (e.g., Concurrent::Map): Provides safe, concurrent access with high performance and minimal contention.
• Fine-grained locks: Protects the smallest necessary scope of shared state. Avoid holding these locks while yielding or running untrusted code.
• Coarse-grained locks: Protects large areas of code or many data structures at once. Use these sparingly as they significantly reduce concurrency.

The async library relies on several core abstractions to manage concurrency:

• Async::Task: Captures sequential computations. It runs using a Fiber and yields control during blocking operations (like sleep, read, or write), allowing other fibers to execute.
• Async::Reactor: A specific implementation of a scheduler that includes an event loop and a selector. It manages the execution of fibers.
• Fiber: The unit of cooperative concurrency. Execution can be transferred from one fiber to another and back.
• Scheduler: An interface that manages fiber execution by intercepting blocking operations and redirecting them to an event loop.
• Event Loop: The part of the scheduler responsible for waiting for events and waking up fibers when they are ready.
• Selector: The component that interacts with the operating system to wait for specific events (e.g., file descriptor readiness).

The Async reactor's event loop typically continues running until all tasks have completed. This is determined by Async::Task#finished?, which checks if a task and all its children have finished execution.

Transient Tasks are a special type of task that do not keep the reactor alive. They are intended for implementation details—background processes that support your application but are not core concurrency processes. If only transient tasks remain at the root of the reactor, the reactor will exit.

Key behaviors of transient tasks:

1. Reactor Exit: They do not prevent the reactor from shutting down. When all non-transient tasks finish, transient tasks are cancelled with an Async::Cancel exception.
2. Tree Hoisting: If a parent task finishes or is cancelled, any transient child tasks are moved up the hierarchy to become children of the parent's parent. This prevents transient tasks from accidentally keeping a sub-tree of tasks alive.

A Barrier manages an unbounded number of tasks. The top-level Barrier method includes built-in load management via an Async::Idler, which prevents system overload by scheduling tasks only when system load is below 80%.

Key Behaviors:

• Automatic Cleanup: The barrier automatically waits for all tasks to complete and stops any outstanding tasks when the block exits.
• Order of Completion: You can process tasks in the order they finish by calling barrier.wait with a block.
• Disabling Load Management: To create tasks as fast as possible without the idler, pass parent: nil to the Barrier call.

# Standard usage with load management
Barrier do |barrier|
	items.each do |item|
		barrier.async do
			process(item)
		end
	end
end

# Processing in order of completion
Barrier do |barrier|
	items.each do |item|
		barrier.async do
			process(item)
		end
	end
	
	barrier.wait do |task|
		result = task.wait
		# Do something with result.
		# break if you don't want to wait for more tasks
	end
end

# Disabling load management
Barrier(parent: nil) do |barrier|
	items.each do |item|
		barrier.async do
			process(item)
		end
	end
end