New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Sort out volatiles in the atomic functions #6368

Merged
merged 2 commits into from Mar 21, 2018

Conversation

Projects
None yet
6 participants
@kjbracey-arm
Contributor

kjbracey-arm commented Mar 15, 2018

Description

Code clean up - the atomic code is confused about the use and meaning of volatile. It's using casts internally where not necessary, and potentially forcing users to insert casts.

Only visible change to application code is that

volatile uint8_t my_volatile;
core_util_atomic_incr_u8(&my_volatile, 1);

will now work - previously it would have required

core_util_atomic_incr_u8((uint8_t *)&my_volatile, 1);

This will continue to work:

uint8_t my_non_volatile;
core_util_atomic_incr_u8(&my_non_volatile, 1);

Change broken into two individual commits to try to avoid impression that the net change is just expecting users to be providing volatile objects - see commit messages for more detail.

(Given the lack of a full suite of atomic operations including load and store, it's probably the case that users will be currently needing to mark stuff volatile just to avoid compiler optimisations. If we do get a full suite of atomic operations, and that would be required for SMP, then there would usually be no need for volatile, but could be in some cases. This change makes us consistent with C11/C++11 regardless).

Pull request type

  • Fix
  • Refactor
  • New target
  • Feature
  • Breaking change

kjbracey-arm added some commits Nov 28, 2017

Remove unnecessary casts
The volatile qualifier on the __LDREX/__STREX prototypes only means that
it's safe to use them on volatile objects. Doesn't mean you actually
have to pass them volatile pointers.

Adding the volatile is a bit like doing strlen((const char *) ptr)
because you've got a non-const pointer.
Add volatile qualifiers to atomic functions
The atomic functions preserve volatile semantics - they only perform the
accesses specified. Add the volatile qualifier to the value pointer to
reflect this. This does not change existing caller code - it's
equivalent to adding a const qualifier to indicate we don't write to
a pointer - it means people can pass us qualified pointers without
casts, letting the compile check const- or volatile-correctness.

This is consistent with C11 <stdatomic.h>, which volatile-qualifies its
equivalent functions.

Note that this useage of volatile has nothing to do with the atomicity -
objects accessed via the atomic functions do not need to be volatile.
But it does permit these calls to be used on objects which have been
declared volatile.

@kjbracey-arm kjbracey-arm requested review from c1728p9, geky and pan- Mar 15, 2018

@kjbracey-arm

This comment has been minimized.

Contributor

kjbracey-arm commented Mar 15, 2018

Do shout if you can see a way this would break any existing code - as far as I can see it's equivalent to adding a missing const qualifier.

Only thing I can think of is someone having a local declaration, or a dummy definition in a unit test.

@pan-

pan- approved these changes Mar 15, 2018

Looks fine to me; it should not break existing code (even at assembly level; I add a quick look and it is identical).
Alignment with c11 standard is much appreciated 👍 .

@geky

geky approved these changes Mar 16, 2018 edited

Good find 👍

@0xc0170

This comment has been minimized.

Member

0xc0170 commented Mar 20, 2018

/morph build

@mbed-ci

This comment has been minimized.

mbed-ci commented Mar 20, 2018

@0xc0170

This comment has been minimized.

Member

0xc0170 commented Mar 20, 2018

/morph build

@mbed-ci

This comment has been minimized.

mbed-ci commented Mar 20, 2018

@0xc0170

This comment has been minimized.

Member

0xc0170 commented Mar 20, 2018

License failure, will restart soon

@0xc0170

This comment has been minimized.

Member

0xc0170 commented Mar 20, 2018

/morph build

@mbed-ci

This comment has been minimized.

mbed-ci commented Mar 20, 2018

Build : SUCCESS

Build number : 1495
Build artifacts/logs : http://mbed-os.s3-website-eu-west-1.amazonaws.com/?prefix=builds/6368/

Triggering tests

/morph test
/morph uvisor-test
/morph export-build
/morph mbed2-build

@mbed-ci

This comment has been minimized.

@mbed-ci

This comment has been minimized.

@0xc0170 0xc0170 added ready for merge and removed needs: CI labels Mar 21, 2018

@cmonr cmonr merged commit 3ddca11 into ARMmbed:master Mar 21, 2018

19 checks passed

AWS-CI uVisor Build & Test Success
Details
ci-morph-build build completed
Details
ci-morph-exporter build completed
Details
ci-morph-mbed2-build build completed
Details
ci-morph-test test completed
Details
continuous-integration/jenkins/pr-head This commit looks good
Details
continuous-integration/travis-ci/pr The Travis CI build passed
Details
travis-ci/docs Local docs testing has passed
Details
travis-ci/events Local events testing has passed
Details
travis-ci/littlefs Passed, code size is 10060B (+0.00%)
Details
travis-ci/mbed2-ATMEL Local mbed2-ATMEL testing has passed
Details
travis-ci/mbed2-MAXIM Local mbed2-MAXIM testing has passed
Details
travis-ci/mbed2-NORDIC Local mbed2-NORDIC testing has passed
Details
travis-ci/mbed2-NUVOTON Local mbed2-NUVOTON testing has passed
Details
travis-ci/mbed2-NXP Local mbed2-NXP testing has passed
Details
travis-ci/mbed2-RENESAS Local mbed2-RENESAS testing has passed
Details
travis-ci/mbed2-SILICON_LABS Local mbed2-SILICON_LABS testing has passed
Details
travis-ci/mbed2-STM Local mbed2-STM testing has passed
Details
travis-ci/tools Local tools testing has passed
Details
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment