charm icon indicating copy to clipboard operation
charm copied to clipboard

LrtsNodeLock has inconsistent behavior when `CMK_SHARED_VARS_UNAVAILABLE` is defined

Open moxcodes opened this issue 5 years ago • 0 comments

For netlrts builds, the CmiNodeLock functionality appears to just refer into the LrtsNodeLock. When shared vars aren't available, the lock is particularly simple (because it doesn't need to worry about concurrency). However, the current implementation in src/util/machine-common-core.C is:

#if CMK_SHARED_VARS_UNAVAILABLE /*Non-smp version of locks*/

LrtsNodeLock LrtsCreateLock(void){ return 0; }
void LrtsLock(LrtsNodeLock lock){ (lock)++; }
void LrtsUnlock(LrtsNodeLock lock){ (lock)--; }
int LrtsTryLock(LrtsNodeLock lock){ return ((lock)?1:((lock)=1,0)); }
void LrtsDestroyLock(LrtsNodeLock lock){ /* empty */ }

#else /*smp version*/

(which seems to be incrementing and decrementing the copied int in the local stack frame). Where in arch/util/lrtslock.h, the typedef is:

#if CMK_SHARED_VARS_UNAVAILABLE
typedef int LrtsNodeLock;
#else

I recognize that this isn't terribly critical, as there is no concurrency in this context, but it should still be the case when running on a single core that:

LrtsNodeLock lock = LrtsCreateLock();
LrtsLock(lock);
if (LrtsTryLock(lock)) {
/*...*/
}

has the behavior that the LrtsTryLock reports that cannot acquire the lock.

moxcodes avatar Dec 18 '20 23:12 moxcodes