-
Notifications
You must be signed in to change notification settings - Fork 12
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
[Brl.Blitz] Mac: bbAtomicAdd (etc) deprecated #261
Comments
I already asked this on discord but maybe it fits here too: in Brl.Treads Function AtomicSwap:Int( target:Int Var,value:Int )
Repeat
Local oldval:Int=target
If CompareAndSwap( Varptr target,oldval,value ) Return oldval
Forever
End Function What happens if a second thread manipulates Asking as CompareAndSwap is called with "oldVal" rather than "target" (which would use the "original" value then). This minimizes the chances I guess. Function AtomicSwap:Int( target:Int Var,value:Int )
Repeat
Local oldval:Int=target
If CompareAndSwap( Varptr target,target,value ) Return oldval
Forever
End Function BUT ... the issue here might remain: If someone really wants to use the returned "oldVal" it might NOT be the one which really was replaced. (this is why there is not just Also I am not sure what GCC creates out of the C-Code, as the function indirection might lead to more temporary variables and thus ways for other threads to manipulate the "original" meanwhile. The generated C code for now looks like this: BBINT brl_threads_CompareAndSwap(BBINT* bbt_target,BBINT bbt_oldValue,BBINT bbt_newValue){
return bbAtomicCAS((int*)&(*bbt_target),(int)bbt_oldValue,(int)bbt_newValue);
}
BBINT brl_threads_AtomicSwap(BBINT* bbt_target,BBINT bbt_value){
do{
BBINT bbt_oldval=*bbt_target;
if(brl_threads_CompareAndSwap(&(*bbt_target),bbt_oldval,bbt_value)!=0){
return bbt_oldval;
}
}while(!(0));
} directly calling bbAtomicCas: Function AtomicSwap:Int( target:Int Var,value:Int )
Repeat
Local oldval:Int=target
If bbAtomicCAS( Varptr target,target,value ) Return oldval
Forever
End Function BBINT brl_threads_AtomicSwap(BBINT* bbt_target,BBINT bbt_value){
do{
BBINT bbt_oldval=*bbt_target;
if(bbAtomicCAS((int*)&(*bbt_target),(int)*bbt_target,(int)bbt_value)!=0){
return bbt_oldval;
}
}while(!(0));
} Dunno if the GCC optimizes it to the same final assembler code at the end. |
We could always force a minimum of C11 and implement support for C11's "atomic" primitives... Rather than "Int", we'd need to define the variable as an atomic int, eg "AtomicInt", which you'd need to use instead for atomic operations. But then it would be guaranteed to work correctly. |
Most important is..if the MacOS stuff will rather sooner than later require a change.
So before it surprises you..maybe be prepared.
Regarding atomicint.
I think an
bbAtomicSet( variable:int var, value:int )
would already help. What it does in the background is maybe not that important
It might even be interesting if it needs something for reading too (depending on memory layout the integer could be a 2 asm command thing..right?)
Might with overloading be interesting for :long too.
Before introducing c11 stuff (I understand that you are a bit eager to try it out :-)) it might be worth to check if the generated code (asm by gcc) uses multiple operations to in that CAS stuff.
If this stuff is not that atomic as we thought... we need to also ensure that TCondVar etc are not relying on such a nonatomic thing.
|
Well, there's nothing to directly replace it with on macOS, since the preferred replacement is to use |
Seems gcc offers atomic functions since 4.8 So doesn't that mean we could use that (for non macos targets)? |
Regarding "C11" ... You made some efforts to have it "C99" compatible (or so) to support old linux boxes with old GCC. Hmm ... but it might mean to keep it "potentially incorrect" as it is now. Couldn't we introduce "Atomic" as a keyword?
Asking as introducing |
While checking for ways to avoid mutexes when simply manipulating integers I saw there is "bbAtomicAdd".
Implementation is:
But OSAtomicAdd32 is deprecated by Apple:
I am not sure if we can - and should - already replace it with the suggested
atomic_fetch_add
The text was updated successfully, but these errors were encountered: