Skip to content
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

critical sections: remove unnecessary volatile #9231

Merged
merged 1 commit into from Jan 7, 2019

Conversation

Projects
None yet
9 participants
@kjbracey-arm
Copy link
Contributor

commented Jan 3, 2019

Description

Critical section count/state variables are synchronised by IRQ disabling and
critical section calls themselves, so do not need to be volatile.

This eliminates a couple of unnecessary reads of the counter variable.

Saves a few bytes of ROM, and a bit of time in speed-critical code.

Pull request type

[ ] Fix
[X] Refactor
[ ] Target update
[ ] Functionality change
[ ] Docs update
[ ] Test update
[ ] Breaking change

Reviewers

@scartmell-arm, @c1728p9

critical sections: remove unnecessary volatile
Critical section count/state variables are synchronised by IRQ disabling and
critical section calls themselves, so do not need to be volatile.

This eliminates a couple of unnecessary reads of the counter variable.

@ciarmcom ciarmcom requested review from c1728p9 and Jan 3, 2019

@ciarmcom

This comment has been minimized.

Copy link
Member

commented Jan 3, 2019

@kjbracey-arm, thank you for your changes.
@c1728p9 @scartmell-arm @ARMmbed/mbed-os-core @ARMmbed/mbed-os-hal @ARMmbed/mbed-os-maintainers please review.

@pan-

pan- approved these changes Jan 3, 2019

Copy link
Member

left a comment

Good change, it would be interesting to have a mention about volatile uses in the handbook at some point.

Funnily enough that change doesn't change code generated: https://godbolt.org/z/za4blY

@kjbracey-arm

This comment has been minimized.

Copy link
Contributor Author

commented Jan 3, 2019

hal_critical_section_exit loses 2 load instructions: https://godbolt.org/z/IOL0lW (although 1 load could have already been saved by proper use of -- operator, and other load should probably be an assert anyway).

The other file is just being done for consistency, and doesn't gain anything because it accesses each variable only once per function.

I'm looking through a few other bits of code - getting paranoid about LTO.

@pan-

This comment has been minimized.

Copy link
Member

commented Jan 3, 2019

It would be interesting to add the -Wodr warning to LTO gcc's config. In my experience, most of the issues I have faced with LTO were related to ODR violation and these may be hard to find.

@kjbracey-arm

This comment has been minimized.

Copy link
Contributor Author

commented Jan 3, 2019

My latest bit of paranoia is implementations of hal_critical_section that don't use PRIMASK, eg nRF52. If they're just doing a memory-mapped write to NVIC, that does have a built-in CPU barrier, but not the compiler barrier you get from the PRIMASK intrinsic or assembler... Do our current compilers reorder normal memory accesses across volatile accesses?

(Without LTO, function calls to other compilation units are compiler barriers, which does a lot of lifting. LTO loses that).

@kjbracey-arm

This comment has been minimized.

Copy link
Contributor Author

commented Jan 3, 2019

Do our current compilers reorder normal memory accesses across volatile accesses?

Immediate answer from an old GCC manual:

Accesses to non-volatile objects are not ordered with respect to volatile accesses. You cannot use a volatile object as a memory barrier to order a sequence of writes to non-volatile memory.

@kjbracey-arm

This comment has been minimized.

Copy link
Contributor Author

commented Jan 3, 2019

Interesting link. asm volatile presumably should force ordering with respect to other volatiles, like C volatile accesses, and that's been fixed. It's not enough though - for a critical section, you still need a memory clobber to act as compiler barrier against the normal code inside, and I see current CMSIS has that.

Raised a CMSIS issue here about NVIC_EnableIRQ lacking a barrier: ARM-software/CMSIS_5#493

@c1728p9

c1728p9 approved these changes Jan 3, 2019

@0xc0170

0xc0170 approved these changes Jan 4, 2019

@0xc0170 0xc0170 added needs: CI and removed needs: review labels Jan 4, 2019

@0xc0170

This comment has been minimized.

Copy link
Member

commented Jan 4, 2019

CI started

@ghost

ghost approved these changes Jan 4, 2019

@pan-

pan- approved these changes Jan 4, 2019

@mbed-ci

This comment has been minimized.

Copy link

commented Jan 7, 2019

Test run: FAILED

Summary: 1 of 7 test jobs failed
Build number : 1
Build artifacts

Failed test jobs:

  • jenkins-ci/mbed-os-ci_build-GCC_ARM
@0xc0170

This comment has been minimized.

Copy link
Member

commented Jan 7, 2019

We are experiencing CI node failures, few jobs were aborted. We are investigating, will restart the jobs once fixed.

cc @ARMmbed/mbed-os-test

@NirSonnenschein

This comment has been minimized.

Copy link
Contributor

commented Jan 7, 2019

re-running to check if CI issue is resolved

@mbed-ci

This comment has been minimized.

Copy link

commented Jan 7, 2019

Test run: SUCCESS

Summary: 11 of 11 test jobs passed
Build number : 2
Build artifacts

@0xc0170 0xc0170 merged commit 965f15d into ARMmbed:master Jan 7, 2019

21 checks passed

continuous-integration/jenkins/pr-head This commit looks good
Details
continuous-integration/travis-ci/pr The Travis CI build passed
Details
jenkins-ci/build-ARM Success
Details
jenkins-ci/build-GCC_ARM Success
Details
jenkins-ci/build-IAR Success
Details
jenkins-ci/cloud-client-test Success
Details
jenkins-ci/dynamic-memory-usage RTOS ROM(+0 bytes) RAM(+0 bytes)
Details
jenkins-ci/exporter Success
Details
jenkins-ci/greentea-test Success
Details
jenkins-ci/mbed2-build-ARM Success
Details
jenkins-ci/mbed2-build-GCC_ARM Success
Details
jenkins-ci/mbed2-build-IAR Success
Details
jenkins-ci/unittests Success
Details
travis-ci/astyle Passed, 0 files
Details
travis-ci/docs Local docs testing has passed
Details
travis-ci/events Passed, runtime is 8964 cycles (-853 cycles)
Details
travis-ci/gitattributestest Local gitattributestest testing has passed
Details
travis-ci/licence_check Local licence_check testing has passed
Details
travis-ci/littlefs Passed, code size is 8372B (+0.00%)
Details
travis-ci/psa-autogen Local psa-autogen testing has passed
Details
travis-ci/tools-py2.7 Local tools-py2.7 testing has passed
Details

@0xc0170 0xc0170 removed the ready for merge label Jan 7, 2019

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.