Josh Ring

This seems like a good idea in principle, have you had any luck making it threadsafe?

How about a more radical approach, where the object is not locked at all for read only access. Objects are only locked if a thread attempts to write to the...

*First situation:* Two concurrent threads access an element almost simultaneously, one writes to an atomic bool to lock the data then proceeds to write to the data. The reading thread...

A very interesting article about how to implement a faster solution to the RW-lock problem we're having. https://locklessinc.com/articles/locks/ Note especially the lowest solution. A public domain (as in, no explicit...

 Crude prototype in C implementing a "dumb spinlock" with a "back-off" for threads querying locks, which starts with 1 CPU cycle then increases, if data is locked, in 75...

I have created a prototype gist with "lock-free" reading, which checks the state did not change during the read else re-read it. Writes are locking. Performance for reading is higher...

Atomically increasing is fine, but the performance of atomic operations is really horrible. So if we can avoid them in a "versioning scheme" it drastically improves performance. Even in C...

> To me it seems that what you're describing looks like a simple versioning scheme. Keeping an forever-atomically-increasing version field seems better for me (no proofs, just some gut feeling)....

Debugging appears to work just fine in this implementation. **EDIT: I only meant it was similar to the Seqlock, but it appears different internally. Assuming the pointers are updated atomically...

The easiest way to adjust on Linux (and mac) is to use the environment variable approach: "export OCIO=/path/to/where/the/filmic-blender/config.ocio" So put export OCIO=cpath or something similar in the code and all...