Closed schuessf closed 3 weeks ago
We have to ensure that all operations on atomic variables are actually performed atomically. Our translation seems to ensure this for read and write operations (I am not 100% sure though).
I think we should ensure this by adding atomic statements in Boogie.
This would also solve the current unsoundness on this branch when using the setting --rcfgbuilder.only.consider.context.switches.at.boundaries.of.atomic.blocks true
aka the "assume no data race"-LBE.
I think we should ensure this by adding atomic statements in Boogie.
This would also solve the current unsoundness on this branch when using the setting
--rcfgbuilder.only.consider.context.switches.at.boundaries.of.atomic.blocks true
aka the "assume no data race"-LBE.
Thanks, that's a good point. With this settings, it actually makes a difference, whether we translate to a single Boogie statement st
or atomic { st }
.
So I guess, the only C expressions where the translation neeeds to be adapted for atomic types, are assignments (also sth. like +=
) and reads (probably only for variables on the heap).
This PR adds support for atomic types (
_Atomic
). To do so, I performed the following steps:__attribute__((atomic))
) for our parser not to crash.CType
. This flag is only set explicitly inCPrimitive
(based on the GCC attribute) and aCNamed
is atomic iff the underlying type is atomic. All other types are currently not atomic. There can be actually an atomic pointer (see here), but we cannot parse the attribute properly at this location and thus don't support atomic pointers.DataRaceChecker
).MemoryHandler::getReadCall
), writes (seeMemoryHandler::getWriteCall
andCHandler::makeAssignment
) and combined read-writes (e.g.++
,--
,*=
, ...) (seeCHandler::makeAtomicAssignmentIfNecessary
) was adapted.