3 ms·
Packing should be fine.. I think the real bug is that the lock is not being handled properly. It should be marked with volatile, and this should signal the com
by jhallenworld 10y ago
Packing should be fine.. I think the real bug is that the lock is not being handled properly. It should be marked with volatile, and this should signal the compiler that it can not be part of a read-modify-write to an unrelated item.
- jjnoakes 10y agoVolatile is never the answer if your question is about locking.
- jhallenworld 10y agoWell you are right in the sense that volatile should not be used in place of locking primitives, and that even when implementing locking primitives, it's not enough (you need memory barriers, probably in an assembly language snippet market as __volatile__). That being said, if the lock variable itself if marked as volatile, the compiler should take the hint based on its simple definition "value could change at any time", and not try to combine in with unrelated read-modify-write accesses. Otherwise why wouldn't you want the compiler to speed up or compress bitfields?
- jjnoakes 10y agoNot only is it not enough, using volatile for locking primitives is a bad idea and should not be done. It slows down the program with no benefits. A correct multi-thrraded program is correct with or without volatile, and so removing volatile can only speed things up and should be done.