On 12/2/24 13:37, Nicklas SB Karlsson wrote:
There is no volatile cast so will also cast type and then there is a
possibility to by misstake cast to wrong type.
Casting is inherently a dangerous operation.
If parameter is passed by value create a local variable with volatile
modifier and assign to this is an option. Not sure it will make any
difference on performance or code.
That would make no sense. Why use volatile on a local? It is never
interacting beyond its local scope.
If address to something in shared memory is not volatile a read or
write will to memory is guaranteed?
Yes and no.
Yes, volatile assures that a memory-transaction will be performed
because volatile informs the compiler that the action may have
non-observable effects and therefore must be executed.
But that doesn't mean it is correct and most often isn't.
The problem, as very well mentioned by Robert, is atomicity. You have to
guarantee that each operation executes as one uninterruptible operation.
Easiest example of problems are read-modify-write cycles in
increment/decrement, but f.x. the x86(_64) architecture allows for
unaligned access. So even simple writing/reading an int will not
necessarily be atomic on that architecture (and lets disregard the
performance penalties of unaligned access).
You need atomic operators for accessing shared memory to solve the
concurrency problem, which also includes guarantees for reading and
writing the data you want.
--
Greetings Bertho
(disclaimers are disclaimed)
_______________________________________________
Emc-developers mailing list
Emc-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-developers
