Thread-safe array building

[foobar_lv]

Thanks again for saving me from the utter nightmare to debug such an issue, and explaining julia internals along the way. I shall now give up, for the time being, and just avoid concurrent writes of object references.

@yuyichao

fixable with some ccall to root the inserted object if the write was successful?

No

Just for curiosity, is this fixable with llvm code to root the inserted object? Or am I misunderstanding, again, some subtlety in the julia implementation?

One could do a copy-pasta from e.g.

set_(X,i,nv) = @inbounds X[i]=nv;
code_llvm(set_, (Vector{Vector{Int64}}, Int64, Vector{Int64}))

exchanging the actual store for a cas (the new object may get rooted even if the write fails. The caller would need to keep the object visible until he has verified whether the write was successful - for example, by actually using the object he attempted to insert in the “failed insert” branch, or in some de-facto unreachable branch that cannot be inferred to be unreachable.

This would, however, probably not be worth it with respect to maintainability and API-uglyness? (otherwise you would have done it already in atomics.jl? or are there other hidden dragons?)

[yuyichao]

@foobar_lv

Just for curiosity, is this fixable with llvm code to root the inserted object?

No. You need to trigger the write barrier and there’s basically no way to express that currently without messing up the codegen.

@foobar_lv

otherwise you would have done it already in atomics.jl?

That’s the plan. Though not in llvm code. There are other part of the code that needs to be ready so this can be done in a generic way and actually being fast.