Benefits: Thread Safety, Simplicity, and Beyond

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
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70

import threading
import time
from typing import List
 
# THE MUTABLE NIGHTMARE — Race condition demonstration
 
class MutableBankAccount:
    """DANGEROUS: Mutable shared state without synchronization"""
    
    def __init__(self, balance: float):
        self.balance = balance  # Shared mutable state!
    
    def transfer_to(self, other: 'MutableBankAccount', amount: float):
        """
        WARNING: This has a race condition!
        Multiple threads can read stale balances and create money from nothing.
        """
        if self.balance >= amount:
            # Time gap between read and write = vulnerability window
            time.sleep(0.0001)  # Simulates any delay
            self.balance -= amount
            other.balance += amount
 
def simulate_race_condition():
    """Demonstrates money appearing from nowhere due to race conditions"""
    alice = MutableBankAccount(1000)
    bob = MutableBankAccount(1000)
    
    print(f"Starting balances: Alice={alice.balance}, Bob={bob.balance}")
    print(f"Total money in system: {alice.balance + bob.balance}")
    
    # Both accounts try to transfer $800 to each other simultaneously
    threads = []
    for _ in range(10):
        t1 = threading.Thread(target=lambda: alice.transfer_to(bob, 100))
        t2 = threading.Thread(target=lambda: bob.transfer_to(alice, 100))
        threads.extend([t1, t2])
    
    for t in threads:
        t.start()
    for t in threads:
        t.join()
    
    print(f"Final balances: Alice={alice.balance}, Bob={bob.balance}")
    print(f"Total money in system: {alice.balance + bob.balance}")
    # BUG: Total may not equal 2000! Money created or destroyed by race.
 
# The "solution" with locks is complex and error-prone:
class SynchronizedBankAccount:
    """Attempted fix with locks — but still fragile"""
    
    def __init__(self, balance: float):
        self.balance = balance
        self._lock = threading.Lock()
    
    def transfer_to(self, other: 'SynchronizedBankAccount', amount: float):
        """
        Still problematic! What's the lock ordering?
        Deadlock if A→B and B→A lock in different orders.
        """
        # Need to acquire BOTH locks — but in what order?
        # This can deadlock if another thread does the reverse!
        with self._lock:
            with other._lock:  # Potential deadlock!
                if self.balance >= amount:
                    self.balance -= amount
                    other.balance += amount
 
# Correct locking requires careful thought about lock ordering,
# potential for deadlock, and extensive testing.

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
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70

from dataclasses import dataclass
from typing import Tuple
 
# IMMUTABLE SOLUTION — Thread safety without locks
 
@dataclass(frozen=True)
class ImmutableAccount:
    """Immutable account — inherently thread-safe"""
    owner: str
    balance: float
 
@dataclass(frozen=True)
class TransferResult:
    """Immutable result of a transfer operation"""
    from_account: ImmutableAccount
    to_account: ImmutableAccount
    success: bool
    message: str
 
def transfer(
    from_acc: ImmutableAccount,
    to_acc: ImmutableAccount,
    amount: float
) -> TransferResult:
    """
    Pure function: takes immutable inputs, returns immutable output.
    No shared state to corrupt. No locks needed.
    """
    if from_acc.balance < amount:
        return TransferResult(
            from_account=from_acc,
            to_account=to_acc,
            success=False,
            message=f"Insufficient funds: {from_acc.balance} < {amount}"
        )
    
    # Create NEW accounts with updated balances
    new_from = ImmutableAccount(from_acc.owner, from_acc.balance - amount)
    new_to = ImmutableAccount(to_acc.owner, to_acc.balance + amount)
    
    return TransferResult(
        from_account=new_from,
        to_account=new_to,
        success=True,
        message=f"Transferred {amount}"
    )
 
# Usage — completely thread-safe without any locks
alice = ImmutableAccount("Alice", 1000)
bob = ImmutableAccount("Bob", 1000)
 
# Any thread can call this safely
result = transfer(alice, bob, 100)
 
# Original accounts are UNCHANGED — other threads still see them
print(f"Original Alice: {alice.balance}")  # Still 1000
print(f"Original Bob: {bob.balance}")      # Still 1000
 
# New state is in the result
print(f"New Alice: {result.from_account.balance}")  # 900
print(f"New Bob: {result.to_account.balance}")      # 1100
 
# In a real system, you'd atomically swap the reference
# using AtomicReference or similar — a single atomic operation
# instead of complex lock choreography.
 
# The key insight:
# - Multiple threads can SHARE immutable objects freely
# - State transitions are represented as new objects
# - The only synchronization needed is for publishing new versions

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
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83

# "SPOOKY ACTION AT A DISTANCE" — The mutation problem
 
class MutableConfig:
    def __init__(self, settings: dict):
        self.settings = settings
 
def process_request(config: MutableConfig):
    """Looks innocent, but shares mutable state"""
    handler = create_handler(config)
    result = handler.process()
    return result
 
def create_handler(config: MutableConfig):
    # Store reference to config for later use
    return RequestHandler(config)
 
class RequestHandler:
    def __init__(self, config: MutableConfig):
        self.config = config  # Stores reference, not copy!
    
    def process(self):
        # Uses config.settings["timeout"]
        timeout = self.config.settings.get("timeout", 30)
        return f"Processing with timeout={timeout}"
 
# The bug scenario:
config = MutableConfig({"timeout": 30, "retries": 3})
 
# Code in module A processes a request
result_a = process_request(config)
 
# Meanwhile, code in module B "temporarily" modifies config
config.settings["timeout"] = 5  # "Just for this one request..."
 
# Code in module C doesn't know about module B's change
result_c = process_request(config)
# BUG: Module C gets timeout=5, not the expected 30!
 
# Worse: if module B stored a reference to config.settings and
# modifies it later, even already-created handlers are affected.
 
# Debugging nightmare:
# - C's code looks correct
# - C's tests pass (they use isolated configs)
# - Bug only appears when A, B, and C interact
# - Cause is in B, effect is in C, symptom reported by user of C
 
# ─────────────────────────────────────────────────────
 
# IMMUTABLE SOLUTION — No action at a distance possible
 
from dataclasses import dataclass
from typing import Dict, Any
import copy
 
@dataclass(frozen=True)
class ImmutableConfig:
    settings: tuple  # Using tuple of tuples for true immutability
    
    @classmethod
    def from_dict(cls, d: Dict[str, Any]) -> 'ImmutableConfig':
        return cls(settings=tuple(sorted(d.items())))
    
    def get(self, key: str, default=None):
        for k, v in self.settings:
            if k == key:
                return v
        return default
    
    def with_setting(self, key: str, value: Any) -> 'ImmutableConfig':
        """Returns NEW config with updated setting"""
        new_settings = dict(self.settings)
        new_settings[key] = value
        return ImmutableConfig.from_dict(new_settings)
 
# Now modifications create new objects:
config1 = ImmutableConfig.from_dict({"timeout": 30, "retries": 3})
config2 = config1.with_setting("timeout", 5)
 
# config1 is UNCHANGED — any code using it still sees timeout=30
# config2 is a NEW object with timeout=5
 
# No spooky action possible — each reference is independent

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
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80

# ALIASING TRAP — Mutable objects shared unexpectedly
 
class MutableDate:
    def __init__(self, year: int, month: int, day: int):
        self.year = year
        self.month = month
        self.day = day
    
    def advance_month(self):
        """Mutates in place"""
        self.month += 1
        if self.month > 12:
            self.month = 1
            self.year += 1
 
class Event:
    def __init__(self, name: str, date: MutableDate):
        self.name = name
        self.date = date  # Stores reference!
 
# The trap:
shared_date = MutableDate(2024, 1, 15)
 
birthday = Event("Birthday", shared_date)
meeting = Event("Meeting", shared_date)  # Same date reference!
 
print(f"Birthday: {birthday.date.month}")  # 1
print(f"Meeting: {meeting.date.month}")    # 1
 
# Someone "reschedules" the meeting...
meeting.date.advance_month()
 
# SURPRISE: Birthday changed too!
print(f"Birthday: {birthday.date.month}")  # 2 — NOT 1!
print(f"Meeting: {meeting.date.month}")    # 2
 
# Both events pointed to the SAME mutable object.
# This is the classic aliasing bug.
 
# ─────────────────────────────────────────────────────
 
# SAFE ALIASING — Immutable objects
 
from dataclasses import dataclass
 
@dataclass(frozen=True)
class ImmutableDate:
    year: int
    month: int
    day: int
    
    def advance_month(self) -> 'ImmutableDate':
        """Returns NEW date, original unchanged"""
        new_month = self.month + 1
        new_year = self.year
        if new_month > 12:
            new_month = 1
            new_year += 1
        return ImmutableDate(new_year, new_month, self.day)
 
@dataclass
class SafeEvent:
    name: str
    date: ImmutableDate
 
# Safe sharing:
shared_date = ImmutableDate(2024, 1, 15)
 
birthday = SafeEvent("Birthday", shared_date)
meeting = SafeEvent("Meeting", shared_date)  # Same date? No problem!
 
# "Rescheduling" creates a NEW date
meeting.date = meeting.date.advance_month()
 
# Birthday is UNCHANGED
print(f"Birthday: {birthday.date.month}")  # 1 — correct!
print(f"Meeting: {meeting.date.month}")    # 2
 
# The original shared_date is still January:
print(f"Shared: {shared_date.month}")  # 1

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
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69

# THE MUTABLE KEY DISASTER
# (Python lists can't be dict keys, but let's simulate with a custom class)
 
class MutablePoint:
    def __init__(self, x, y):
        self.x = x
        self.y = y
    
    def __hash__(self):
        return hash((self.x, self.y))  # Hash depends on mutable state!
    
    def __eq__(self, other):
        return self.x == other.x and self.y == other.y
 
# The disaster scenario:
point = MutablePoint(1, 2)
data = {point: "Important data!"}
 
# The data is present
print(f"point in data: {point in data}")  # True
print(f"data[point]: {data[point]}")       # "Important data!"
 
# Now mutate the key...
point.x = 999
 
# THE DATA IS "LOST"!
print(f"point in data: {point in data}")  # False!
try:
    print(data[point])
except KeyError:
    print("KeyError — data not found!")  # This happens!
 
# The data is still IN the dictionary — but unreachable!
# The hash bucket where we stored it (based on x=1, y=2)
# is different from where we're looking (x=999, y=2)
 
print(f"Dictionary still has 1 item: {len(data)}")  # 1
 
# Memory leak: data can't be accessed or garbage collected
# until the dictionary itself is destroyed.
 
# ─────────────────────────────────────────────────────
 
# IMMUTABLE KEYS — Always safe
 
from dataclasses import dataclass
 
@dataclass(frozen=True)  # frozen ensures hash stability
class ImmutablePoint:
    x: int
    y: int
 
# Safe usage:
point_key = ImmutablePoint(1, 2)
safe_data = {point_key: "Important data!"}
 
# This would raise an error — immutability enforced:
# point_key.x = 999  # FrozenInstanceError!
 
# Key is always where we expect it
print(f"safe_data[point_key]: {safe_data[point_key]}")  # Works forever!
 
# To use a different key, create a new point:
new_key = ImmutablePoint(999, 2)
safe_data[new_key] = "Different data"
 
# Original key still works perfectly
print(f"Original: {safe_data[point_key]}")  # "Important data!"
print(f"New: {safe_data[new_key]}")          # "Different data"

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
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106

from dataclasses import dataclass
from functools import lru_cache
from typing import Tuple
import hashlib
 
# CACHING WITH IMMUTABLE OBJECTS
 
@dataclass(frozen=True)
class Document:
    """Immutable document — safe to cache operations on it"""
    title: str
    content: str
    author: str
    
    @property
    def word_count(self) -> int:
        """
        Expensive operation — but can be cached!
        Since Document is immutable, result never changes.
        """
        return len(self.content.split())
    
    @property 
    def content_hash(self) -> str:
        """
        Cryptographic operations are expensive.
        Immutability means we can compute once and cache.
        """
        return hashlib.sha256(self.content.encode()).hexdigest()
 
# The @lru_cache decorator enables memoization
# This only works safely because Document is immutable (hashable)
 
@lru_cache(maxsize=1000)
def analyze_sentiment(doc: Document) -> float:
    """
    Expensive ML operation — call external API.
    With immutable Document, we can safely cache by document.
    """
    # Simulated expensive operation
    print(f"  [Expensive API call for: {doc.title}]")
    return 0.75  # Simulated positive sentiment
 
@lru_cache(maxsize=1000)  
def extract_keywords(doc: Document) -> Tuple[str, ...]:
    """Another expensive operation, safely cached"""
    # Simulated NLP processing
    print(f"  [Expensive NLP for: {doc.title}]")
    words = doc.content.lower().split()
    return tuple(w for w in set(words) if len(w) > 5)
 
# Usage:
doc = Document(
    title="Introduction to Immutability",
    content="Immutability provides thread safety and simplicity...",
    author="Engineering Team"
)
 
print("First calls — expensive operations run:")
sentiment1 = analyze_sentiment(doc)
keywords1 = extract_keywords(doc)
 
print("
Second calls — cached results returned instantly:")
sentiment2 = analyze_sentiment(doc)  # No "expensive" message!
keywords2 = extract_keywords(doc)    # No "expensive" message!
 
# Same document = same cached result
print(f"
Results identical: {sentiment1 == sentiment2}")
 
# Creating the "same" document gives cache hit too:
doc_copy = Document(
    title="Introduction to Immutability",
    content="Immutability provides thread safety and simplicity...",
    author="Engineering Team"
)
print("
'Copy' with same values — cache hit:")
sentiment3 = analyze_sentiment(doc_copy)  # Cache hit!
 
# ─────────────────────────────────────────────────────
 
# STRUCTURAL SHARING — Efficient updates with caching
# Immutable data structures can share unchanged parts
 
@dataclass(frozen=True)
class ImmutableList:
    """
    Conceptual: immutable list using structural sharing.
    Real implementations (e.g., Pyrsistent) are more sophisticated.
    """
    _items: Tuple
    
    def prepend(self, item) -> 'ImmutableList':
        # New list shares tail with old list
        return ImmutableList((item,) + self._items)
    
    def __iter__(self):
        return iter(self._items)
    
    def __len__(self):
        return len(self._items)
 
# Libraries like Pyrsistent, Immutables provide efficient implementations
# that use structural sharing for O(log n) updates instead of O(n) copies

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
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108

from dataclasses import dataclass
from typing import List, Callable
from functools import reduce
 
# IMPURE FUNCTION — Depends on mutable state
total_calls = 0  # Global mutable state
 
def impure_add(a: int, b: int) -> int:
    global total_calls
    total_calls += 1  # Side effect!
    return a + b
 
# Different results over time (the side effect changes global state)
print(f"Calls before: {total_calls}")  # 0
impure_add(2, 3)
print(f"Calls after: {total_calls}")   # 1
 
# ─────────────────────────────────────────────────────
 
# PURE FUNCTIONS WITH IMMUTABLE DATA
 
@dataclass(frozen=True)
class Order:
    items: tuple
    customer: str
    
    @property
    def total(self) -> float:
        return sum(item.price for item in self.items)
 
@dataclass(frozen=True)
class OrderItem:
    name: str
    price: float
    quantity: int
 
# Pure function: Order → Order (new order with discount)
def apply_discount(order: Order, discount: float) -> Order:
    """
    Pure function:
    - No side effects
    - Same input always produces same output
    - Original order unchanged
    """
    discounted_items = tuple(
        OrderItem(item.name, item.price * (1 - discount), item.quantity)
        for item in order.items
    )
    return Order(items=discounted_items, customer=order.customer)
 
# Pure function composition
def apply_bulk_discount(order: Order) -> Order:
    total_quantity = sum(item.quantity for item in order.items)
    if total_quantity >= 10:
        return apply_discount(order, 0.1)
    return order
 
def apply_loyalty_discount(order: Order, loyalty_years: int) -> Order:
    if loyalty_years >= 5:
        return apply_discount(order, 0.05)
    return order
 
# Compose pure functions into a pipeline
def process_order(order: Order, loyalty_years: int) -> Order:
    """
    Pure transformation pipeline.
    Each step returns a new immutable order.
    """
    order = apply_bulk_discount(order)
    order = apply_loyalty_discount(order, loyalty_years)
    return order
 
# Usage:
original = Order(
    items=(
        OrderItem("Widget", 10.0, 5),
        OrderItem("Gadget", 25.0, 8)
    ),
    customer="Alice"
)
 
processed = process_order(original, loyalty_years=7)
 
print(f"Original total: {original.total}")   # Unchanged!
print(f"Processed total: {processed.total}") # With discounts
 
# Key benefit: you can REASON about this code purely logically.
# No hidden state, no action at a distance, no temporal dependencies.
 
# ─────────────────────────────────────────────────────
 
# DECLARATIVE DATA TRANSFORMATIONS
# With immutability, you describe WHAT, not HOW
 
orders = [
    Order((OrderItem("A", 10, 1),), "Alice"),
    Order((OrderItem("B", 20, 2),), "Bob"),
    Order((OrderItem("C", 30, 3),), "Charlie"),
]
 
# Declarative: filter, map, reduce — all return new data
high_value_orders = [o for o in orders if o.total > 25]
discounted = [apply_discount(o, 0.1) for o in high_value_orders]
total_revenue = sum(o.total for o in discounted)
 
# Each step produces new immutable data.
# Original 'orders' list unchanged.
# Easy to understand, test, and parallelize.