Threads acquiring an exclusive lock on an Atomic_RW_Mutex wait forever.

[kb9113]

Context

Odin:    dev-2025-05:843648c81
OS:      Fedora Linux 42 (Workstation Edition), Linux 6.14.6-300.fc42.x86_64
CPU:     AMD Ryzen 9 7900 12-Core Processor
RAM:     31229 MiB
Backend: LLVM 20.1.3

Expected Behavior

After an Atomic_RW_Mutex is unlocked using sync.shared_unlock any thread waiting to acquire the rw mutex using sync.lock continues past the lock.

Current Behavior

Theads waiting on acquiring an exclusive lock appear to wait forever if they attempt to acquire the exclusive lock while a thread has a shared lock. Even when the other thread releases the shared lock later.

Failure Information (for bugs)

Steps to Reproduce

In the below code I would expect that tast1 would run and acquire the RW Mutex for reading. Then task2 would try to acquire the RW Mutex for writing, would wait for task1 to release it then would continue though the code.

However, When I run the code, I get

before lock
task1 done

Then the program appears to wait on acquiring the lock for writing forever.

main :: proc()
{
    wg : sync.Wait_Group

    t1 := thread.create(task1)
    t1.init_context = context
    t1.user_index = 1
    t1.data = &wg

    t2 := thread.create(task2)
    t2.init_context = context
    t2.user_index = 1
    t2.data = &wg

    sync.wait_group_add(&wg, 2)

    thread.start(t1)
    thread.start(t2)

    sync.wait_group_wait(&wg)
}

rw_mutex : sync.Atomic_RW_Mutex

task1 :: proc(t: ^thread.Thread)
{
    sync.shared_lock(&rw_mutex)
    time.sleep(time.Second * time.Duration(2))
    sync.shared_unlock(&rw_mutex)

    sync.wait_group_done((cast(^sync.Wait_Group)t.data))

    fmt.println("task1 done")
}

task2 :: proc(t: ^thread.Thread)
{
    time.sleep(time.Second * time.Duration(1))

    fmt.println("before lock")
    sync.lock(&rw_mutex)
    fmt.println("after lock")
    time.sleep(time.Second * time.Duration(1))
    sync.unlock(&rw_mutex)

    sync.wait_group_done((cast(^sync.Wait_Group)t.data))

    fmt.println("task2 done")
}

Failure Logs

[Feoramund]

I can confirm replication of this bug. I'll see if I can fix this today.