Blender Git Commit Log

Git Commits -> Revision 3c1f3c0

Revision 3c1f3c0 by Bastien Montagne (master)
November 25, 2017, 22:14 (GMT)
Fix for Fix (c): broken atomic lock in own bmesh code.

That was a nasty one, Debug build would never have any issue (even tried
with 64 threads!), but Release build would deadlock nearly immediately,
even with only 2 threads!

What happened here (I think) is that gcc optimizer would generate a
specific path endlessly looping when initial value of virtual_lock was
FLT_MAX, by-passing re-assignment from v_no[0] and the atomic cas
completely. Which would have been correct, should v_no[0] not have been
shared (and modified) by multiple threads. ;)

Idea of that (broken) for loop was to avoid completely calling the
atomic cas as long as v_no[0] was locked by some other thread, but...
Guess the avoided/missing memory barrier was the root of the issue here.

Lesson of the evening: Remember kids, do not trust your compiler to
understand all possible threading-related side effects, and be explicit
rather than elegant when using atomic ops!

Side-effect lesson: do check both release and debug builds when messing
with said atomic ops...

Commit Details:

Full Hash: 3c1f3c02c60f6ace330c53299640a6ca6499b6b9
Parent Commit: dd6c918
Lines Changed: +7, -5

1 Modified Path:

/source/blender/bmesh/intern/bmesh_mesh.c (+7, -5) (Diff)
By: Miika HämäläinenLast update: Nov-07-2014 14:18MiikaHweb | 2003-2021