The page of the manual on multi-threading warns about memory-unsafe operations in data race conditions, and gives the advice of using locks or atomic operations on Threads.Atomic objects to work around that problem. I get that this applies e.g. when you @spawn different tasks that may write and rea…

@async only has 1 thread running so it’s thread-safe by construction I believe.

So, if you have multiple available threads, and schedule two tasks with @async, are they both guaranteed to run in the same thread? Which one? The one in which they were scheduled, maybe?

julia> a = Int[] Int64[] julia> @sync for _ in 1:10 @async for _ in 1:10 push!(a, Threads.threadid()) sleep(0.01) end @async for _ in 1:10 push!(a, Threads.threadid()) end end julia> all(==(1), a) true

Xref [image] Task scheduling semantics Internals & Design I needed to know about the new behavior but was also confused about where to look. To link up some information I found: The co-scheduling behavior of @async tasks with their parent tasks was discussed in https://g…

[image] jling: @async only has 1 thread running so it’s thread-safe by construction I believe Yes, this is correct if you’re worried about data races which are only a concern for true parallelism. You may, however still need locks if there’s any chance that a Task (green thread) might yield …

[image] c42f: You may, however still need locks if there’s any chance that a Task (green thread) might yield to another task which manipulates the same data. I cannot grasp this, could you please elaborate a bit? (e.g. What counts as “maniupulating the same data”?)

Consider the following program: using StructArrays function f(a, b) v = StructVector((a, b)) @sync begin @async push!(v, (1, 2)) x = @inbounds v[end] @show x end end Is this program well-defined for f(::Vector, ::Vector)? Likely yes. (But there is no public AP…

Thanks for this great explanation! This seems like a source of rare but hard to find bugs. A quick mental search in my recent programs did not found any possible instance of this, but it seems entirely possible, especially with @debug. Shared memory is evil.

[image] tkf: The semantics of @async and @spawn tasks allow arbitrary interleaving of “pieces of code.” The only difference is that the granularity of the “pieces of code”. In @async , it’s the parts of the code delimited by the yield points (“I/O” operations). In @spawn , it’s individual machin…

[image] tisztamo: Shared memory is evil. We shake hands with the devil, and get the performance :smiling_imp: [image] c42f: you need the program to be free of data races in order to interpret the execution as a sequentially consistent “interleaving” Yeah, good point. I avoided mention…

[image] tisztamo: Shared memory is evil. As someone who was a BeOS developer, I strongly disagree. The important thing is to understand what you are doing. Message passing through channels and using synchronization primitives is really not that hard. In many ways multithreaded programming is …

Is `@async` memory safe?

General Usage

ericphanson August 18, 2021, 1:00am 5

Xref

Topic		Replies	Views
@async macro not recommended? General Usage	5	557	April 3, 2024
Task migration & data-race freedom General Usage task	7	682	March 28, 2022
Using Tasks 101 Teaching & Outreach tutorials , task	15	1045	July 30, 2024
Task scheduling semantics Internals & Design	6	1299	August 12, 2021
@spawn and @async in producer-consumer problem Performance multithreading	4	749	December 5, 2022

Is `@async` memory safe?

Related topics