3 ms·
What about a data race? Theoretically, the function that memset_ptr points to could be changed between when it is checked and when it would be run.
by spott 12y ago
What about a data race? Theoretically, the function that memset_ptr points to could be changed between when it is checked and when it would be run.
- Karellen 12y agoIf you have multiple threads accessing a shared (mutable) variable in your program, even a shared volatile variable, then you need to guard every access to that variable (which, in this case, includes every function call through memset_ptr) with proper thread synchronisation primitives. Marking a variable "volatile" is not enough to prevent data races in a multi-threaded environment. If you've put a semaphore, or mutex lock, or whatever around your calls through memset_ptr(), the transformations will all take place inside the lock, and data races should not be an issue.
- spott 12y agoI think you missed my point. memset_ptr is a const (not changed by this program... theoretically) volatile (allowed to be changed by the system, theoretically) pointer to memset. In THIS PARTICULAR CASE, memset_ptr points to memset. The compiler however doesn't know that it won't change due to another processes, but we do. So the compiler shouldn't be able to optimize out the call directly to the function pointer because it introduces a possible race condition: the program reads that memset_ptr points to memset, then the pointer changes (due to some other process changing it), but the program still calls memset, and not memset_ptr. The optimization allows for a possible race condition to occur.
- tedunangst 12y agoThat race exists regardless. Many systems will execute this as loading the pointer into a register, them jumping to it. The value could change between those two instructions.