Thanks to visit codestin.com
Credit goes to github.com

Skip to content

Use atomics for system_working global #13333

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 2 commits into from
May 15, 2025

Conversation

jhawthorn
Copy link
Member

Although it almost certainly works in this case, volatile should not be used for multi-thread synchronization. Using atomics instead avoids warnings from TSan.

This also simplifies some logic, as system_working was previously only ever assigned to 1, so --system_working <= 0 should always return true (unless it underflowed).

Fixes:

❯ TSAN_OPTIONS="halt_on_error=1:strip_path_prefix=$(pwd)/" ./miniruby -e 'Thread.new{}.join'
==================
WARNING: ThreadSanitizer: data race (pid=3458317)
  Write of size 4 at 0x555555e03118 by main thread:
    #0 native_stop_timer_thread thread_pthread.c:3128:15 (miniruby+0x478100) (BuildId: 15fb730468deee86fe6bbe9ca8c7e33a06fca03b)
    #1 rb_thread_stop_timer_thread thread.c:4701:37 (miniruby+0x478100)
    #2 rb_ec_cleanup eval.c:262:5 (miniruby+0x26cccc) (BuildId: 15fb730468deee86fe6bbe9ca8c7e33a06fca03b)
    #3 ruby_run_node eval.c:319:12 (miniruby+0x26d074) (BuildId: 15fb730468deee86fe6bbe9ca8c7e33a06fca03b)
    #4 rb_main main.c:42:12 (miniruby+0x14bc7c) (BuildId: 15fb730468deee86fe6bbe9ca8c7e33a06fca03b)
    #5 main main.c:62:12 (miniruby+0x14bc7c)

  Previous read of size 4 at 0x555555e03118 by thread T1:
    #0 timer_thread_func thread_pthread.c:3008:12 (miniruby+0x483e94) (BuildId: 15fb730468deee86fe6bbe9ca8c7e33a06fca03b)

  Location is global 'system_working' of size 4 at 0x555555e03118 (miniruby+0x8af118)

  Thread T1 (tid=3458319, running) created by main thread at:
    #0 pthread_create <null> (miniruby+0xc1fd9) (BuildId: 15fb730468deee86fe6bbe9ca8c7e33a06fca03b)
    #1 rb_thread_create_timer_thread thread_pthread.c:3121:5 (miniruby+0x478475) (BuildId: 15fb730468deee86fe6bbe9ca8c7e33a06fca03b)
    #2 Init_Thread thread.c:5589:5 (miniruby+0x47a908) (BuildId: 15fb730468deee86fe6bbe9ca8c7e33a06fca03b)
    #3 rb_call_inits inits.c:64:5 (miniruby+0x2b9cdc) (BuildId: 15fb730468deee86fe6bbe9ca8c7e33a06fca03b)
    #4 ruby_setup eval.c:86:9 (miniruby+0x26b8d8) (BuildId: 15fb730468deee86fe6bbe9ca8c7e33a06fca03b)
    #5 ruby_init eval.c:98:17 (miniruby+0x26ba75) (BuildId: 15fb730468deee86fe6bbe9ca8c7e33a06fca03b)
    #6 rb_main main.c:41:5 (miniruby+0x14bc6a) (BuildId: 15fb730468deee86fe6bbe9ca8c7e33a06fca03b)
    #7 main main.c:62:12 (miniruby+0x14bc6a)

SUMMARY: ThreadSanitizer: data race thread_pthread.c:3128:15 in native_stop_timer_thread
==================

Copy link

launchable-app bot commented May 14, 2025

Tests Failed

✖️no tests failed ✔️61849 tests passed(1 flake)

Although it almost certainly works in this case, volatile is best not
used for multi-threaded code. Using atomics instead avoids warnings from
TSan.

This also simplifies some logic, as system_working was previously only
ever assigned to 1, so --system_working <= 0 should always return true
(unless it underflowed).
@jhawthorn jhawthorn force-pushed the system_working_atomic branch from 20549e4 to c03ba3d Compare May 14, 2025 22:07
@jhawthorn jhawthorn merged commit d67d169 into ruby:master May 15, 2025
82 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

1 participant