Content originally posted in LPCWare by a.unique.identifier on Wed May 23 07:52:04 MST 2012
I'm trying to use a semaphore to control a common resource. I'm bascially using a slightly modified version of code from the Joseph Yiu book, which uses the CMSIS __LDREXW and __STREXW calls. Much to my surprise, an interrupt handler takes control of the common resource without (apparently) regard for the fact that the resource is already being used! Am I missing some basic concept here?
Here is the semaphore code:
volatile uint32_t MuxPortLocked; // The mutex
/*
* return TRUE if the lock was successful, else FALSE
*/
uint32_t MuxPortLockSuccessful(void){
[INDENT] // See if the device is already locked
[/INDENT][INDENT] if (__LDREXW(&MuxPortLocked) == 0){
[/INDENT][INDENT] // The device isn't locked
[/INDENT][INDENT] if (__STREXW(1, &MuxPortLocked) != 0)
[/INDENT][INDENT][INDENT] return (FALSE); // failed
[/INDENT][/INDENT][INDENT] else
[/INDENT][INDENT][INDENT] return (TRUE); // success
[/INDENT][/INDENT][INDENT] }else{
[/INDENT][INDENT][INDENT] return(FALSE); // failed
[/INDENT][/INDENT][INDENT] }
[/INDENT] }
void MuxPortUnlock(void){
[INDENT] MuxPortLocked = FALSE;
[/INDENT] }
Here is the code (same for both the interrupt handler as well as the "normal" C code) used to access the common resource:
while (!MuxPortLockSuccessful());
// Do something with the common resource
MuxPortUnlock();
I single stepped through the "normal" code, which is protected by the semaphore, and low and behold I hit a breakpoint in my (systick) interrupt handler, which should have been blocked by the initial "while" statement.
Finally, should I use the CMSIS __CLREX commenad instead of simply clearing the semaphore?
