# Optimistic Concurrency Control

**URL:** <https://discourse.julialang.org/t/optimistic-concurrency-control/12402>\
**Category:** Julia at Scale\
**Tags:** multithreading\
**Created:** [July 15, 2018, 11:30pm UTC](https://discourse.julialang.org/t/optimistic-concurrency-control/12402 "2018-07-15T23:30:36Z")\
**Posts on this page:** 3\
**Page:** 1

<div class="post-metadata">

**Author:** ![SohamTamb](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/sohamtamb/32/4479_2.png) [@SohamTamb](https://discourse.julialang.org/u/SohamTamb)\
**Post date:** [July 15, 2018, 11:30pm UTC](https://discourse.julialang.org/t/optimistic-concurrency-control/12402/1 "2018-07-15T23:30:36Z")

</div>

I am considering implementing a parallel (multi-threaded) algorithm using optimistic concurrency control. i.e. you allow race conditions to happen but ensure the correctness is not affected.

I was hoping to find information on race-conditions.

For example

```julia
s = 100
a = 0
@threads for i in 1:2 
   a += s
end

```

Is it guaranteed that the final value of `a` will be `s` or `2*s`?

More specific info: This is what I’m looking to implement  
[https://kulslide.com/download/avoiding-locks-and-atomic-instructions-in-shared-memory-parallel-bfs-using-optimistic-parallelization-\_59fd803ad64ab2f105a35e8f\_pdf](https://kulslide.com/download/avoiding-locks-and-atomic-instructions-in-shared-memory-parallel-bfs-using-optimistic-parallelization-_59fd803ad64ab2f105a35e8f_pdf)

---

<div class="post-metadata">

**Author:** ![yuyichao](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/yuyichao/32/20_2.png) [@yuyichao](https://discourse.julialang.org/u/yuyichao)\
**Post date:** [July 16, 2018, 1:07am UTC](https://discourse.julialang.org/t/optimistic-concurrency-control/12402/2 "2018-07-16T01:07:55Z")

</div>

> [@SohamTamb](#):
>
> Is it guaranteed that the final value of `a` will be `s` or `2*s` ?

No. What you are creating is a data race that is undefined behavior (in LLVM and C (i.e. runtime) level so there’s little we can do).

Without reading the paper you link, I believe what you want to use is relaxed atomics. In short, race on data is undefined behavior (UB) but race on atomics are not so the only possible race you can allow that doesn’t introduce UB is to use atomics. For the current language standard and for all relevant architectures, the way to use atomics without introducing atomic instructions and with minimum performance impact is to use relaxed atomics. It also fits the title of the paper very well since,

1. it doesn’t use atomic instruction
2. it **DOES** disable certain compiler optimizations, which has to be the case since those optimizations can easily make your code invalid with concurrent access.

Julia currently doesn’t support relaxed atomics directly. However, you can implement them fairly easily with `llvmcall`. You should be able to replace the value of `a` with a `Ref(1)` and use `llvmcall` to implement atomic load and store with relaxed ordering on it. You can check the implementation of `Atomic` together with [LLVM Language Reference Manual — LLVM 18.0.0git documentation](https://llvm.org/docs/LangRef.html) to figure out how you can do that.

---

<div class="post-metadata">

**Author:** ![yuyichao](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/yuyichao/32/20_2.png) [@yuyichao](https://discourse.julialang.org/u/yuyichao)\
**Post date:** [July 16, 2018, 1:12am UTC](https://discourse.julialang.org/t/optimistic-concurrency-control/12402/3 "2018-07-16T01:12:32Z")

</div>

Do note that reasonning about relaxed atomics (or basically any race that doesn’t give you ordering guarantee) can be extremely difficult, something I would certainly not do myself out of few well defined local context. For further reading, search “out of thin air value”.