• Home
  • Features
  • Pricing
  • Docs
  • Announcements
  • Sign In

JuliaLang / julia / 1377
77%

Build:
DEFAULT BRANCH: master
Ran 16 Dec 2025 11:57AM UTC
Jobs 0
Files 0
Run time –
Badge
Embed ▾
README BADGES
x

If you need to use a raster PNG badge, change the '.svg' to '.png' in the link

Markdown

Textile

RDoc

HTML

Rst

pending completion
1377

push

buildkite

web-flow
threads: Implement asymmetric atomic fences (#60311)

Asymmetric atomic fences are a performance optimization of regular
atomic fences (the seq_cst version of which we expose as
`Base.Threads.atomic_fence`). The problem with these regular fences is
that they require a CPU fence instruction, which can be very expensive
and is thus unsuitable for code in the hot path. Asymmetric fences on
the other hand split an ordinary fence into two: A `light` side where
the fence is extremely cheap (only a compiler reordering barrier) and a
`heavy` side where the fence is very expensive.

Basically the way it works is that the heavy side does a system call
that issues an inter-processor-interrupt (IPI) which then issues the
appropriate barrier instruction on the other CPU (i.e. both CPUs will
have issues a barrier instruction, one of them just does it
asynchronously due to interrupt).

The `light` and `heavy` naming here is taken from C++ PR1202R5 [1],
which is the proposal for the same feature in the C++ standard library
(to appear in the next iteration of the C++ concurrency spec).

On the julia side, these functions are exposed as
`Threads.atomic_fence_light` and `Threads.atomic_fence_heavy`. The light
side lowers to `fence singlethread` in llvm IR (the Core.Intrinsic
atomic_fence is adjusted appropriately to faciliate this). The heavy
side has OS-specifc implementations, where:

1. Linux/FreeBSD try to use the `membarrier` syscall or a fallback to
`mprotect` for systems that don't have it.
2. Windows uses the `FlushProcessWriteBuffers` syscall.
3. macOS uses an implementation from the dotnet runtime
(https://github.com/dotnet/runtime/pull/44670), which the dotnet folks
have checked with Apple does the right thing by happenstance (i.e. an
IPI/memory barrier is needed to execute the syscall), but looks a little
nonsensical by itself. However, since it's what Apple recommended to
dotnet, I don't see much risk here, though I wouldn't be surprised if
Apple added a pr... (continued)
Source Files on build 1377
Detailed source file information is not available for this build.
  • Back to Repo
  • 8eadaf9c on github
  • Prev Build on master (#1375)
  • Next Build on master (#1378)
STATUS · Troubleshooting · Open an Issue · Sales · Support · CAREERS · ENTERPRISE · START FREE · SCHEDULE DEMO
ANNOUNCEMENTS · TWITTER · TOS & SLA · Supported CI Services · What's a CI service? · Automated Testing

© 2025 Coveralls, Inc