As we all know, changing the state of an object that is attached to the graphics must be done in the simpleUpdate() thread, otherwise we throw an exception. How about getter functions (i.e. retrieving a buffer from a mesh)? Are these also thread-restricted?
@KevinKostlan said: As we all know, changing the state of an object that is attached to the graphics must be done in the simpleUpdate() thread, otherwise we throw an exception. How about getter functions (i.e. retrieving a buffer from a mesh)? Are these also thread-restricted?
Not safe if you care about consistency even slightly. Unless you want to get into a longer discussion about thread caches, memory barriers, etc… better to just consider all non-thread-safe data non-thread-safe for reading or writing.
What is the actual use case?
1 Like
They are not safe per se, now if you exacly know who is writing, how your happens before relation is ect. you can sue some. But a rule of thumb is better, don’t do it.
Tip, use a callable that you enqueue into the application, and let it just return the value(Or a bunch of them depending on use case).
Ok thanks. So they wont throw the exception like the setter methods do but could give weird results?
@KevinKostlan said: Ok thanks. So they wont throw the exception like the setter methods do but could give weird results?
Well, it depends. It might throw an exception if you are reading a buffer while something else has reset its limit() or something. In the best case, you get stale (could be an old value even though some other thread has already updated it) or inconsistent data. In the worst case, trying to read inconsistent data will cause an exception.
Better to just not do it.
Put it this way, if you eventually get to a point where you understand what a memory barrier is and how it has an effect in this conversation then you might be to the point where you’d have the proper knowledge to decide when you could and couldn’t get away with this… and then you still probably would never do it.