Skip to content

Highs binary semaphore acquire: fix tsan CI error - #3475

Open
galabovaa wants to merge 2 commits into
latestfrom
highs-binary-semaphore-acquire
Open

galabovaa wants to merge 2 commits into
latestfrom
highs-binary-semaphore-acquire

Conversation

@galabovaa

Copy link
Copy Markdown
Contributor

Description

Fixes TSAN error that popped up in an unrelated PR:

https://github.com/ERGO-Code/HiGHS/actions/runs/40368145015/job/121731331326?pr=3409

Checklist

  • I have read the contributing guidelines
  • This PR targets the latest branch
  • Tests are passing
  • Documentation was updated where relevant
  • This PR is not primarily AI-generated (per the AI contributions policy in CONTRIBUTING.md)

@galabovaa galabovaa self-assigned this Oct 27, 2026
@galabovaa
galabovaa requested a review from filikat October 27, 2026 16:52
@codecov

codecov Bot commented Oct 27, 2026

Copy link
Copy Markdown

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 75.19%. Comparing base (410e953) to head (942463a).
⚠️ Report is 9 commits behind head on latest.

Additional details and impacted files
@@            Coverage Diff             @@
##           latest    #3475      +/-   ##
==========================================
- Coverage   75.19%   75.19%   -0.01%     
==========================================
  Files         460      460              
  Lines      112413   112413              
  Branches    17825    17827       +2     
==========================================
- Hits        84532    84524       -8     
- Misses      27599    27607       +8     
  Partials      282      282              

☔ View full report in Codecov by Harness.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:
  • ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

@filikat filikat left a comment •

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks! This makes sense to me.

If anyone's interested:

  • the first load doesn't need to be tagged acquire, because it calls try_acquire() anyway. Since the loop runs many times, it's better to keep it relaxed.
  • the exchange must be tagged acquire, or it doesn't synchronise with the release in release().
  • the last load needs to be tagged acquire to guard against the possibility (quite remote) of a spurious wakeup of the condition variable, while another thread is pre-empted during release() just before acquiring the mutex.

This branch has not been deployed

No deployments
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.

2 participants