Possible bug in cxa_guard?

[renebarto]

Hi Rene, I've been trying to get a grasp of how Circle works, especially the multi-core part. I'm amazed with the complexity, but hats off for the work so far.

I was trying to build a small application that simply starts all cores, and wait for a character on the UART. If really down to the bare minimum, this works. I've however re-implemented the singletons such that they use a static instance, that gets created whenever a function is called to retrieve it. Like this:

class A
{
private:
A();
public:
...
}
A& GetA();

Which is then implemented as:
A& GetA()
{
static A a;
a.Initialize(); // if needed
return a;
}

This way I don't have to keep the pThis.

Ok, now on to the problem. Due to the fact that I use a static, the __cxa_guard_acquire function gets called (and will return 1 off course when the variable needs to be created).
When I tell the system to halt everything, the interrupt system is used to send messages to other cores to stop, which then retrieves the static interrupt system again (which clearly does not need to be created at that time).
__cxa_guard_acquire however calls GuardAcquire, which checks whether any other core is currently holding the guard. And here is where things go wrong:

static void GuardAcquire (void)
{
int nThisCore = (int) CMultiCoreSupport::ThisCore ();

int nGuardCore;
while (      (nGuardCore = AtomicCompareExchange (&s_nGuardCore, LOCK_FREE, nThisCore))
	  != LOCK_FREE
       && nGuardCore != nThisCore)
{
	// just wait
}

s_nGuardAcquireCount++;

}

static void GuardRelease (void)
{
assert (s_nGuardAcquireCount > 0);
if (--s_nGuardAcquireCount)
{
AtomicSet (&s_nGuardCore, LOCK_FREE);
}
}

After the first time core 0 acquires the guard, the counter s_nGuardAcquireCount is incremented, and the core holding the guard s_nGuardCore is set to 0.
When it is released, the check is first whether s_nGuardAcquireCount is not 0, and then it is decremented. I would expect the s_nGuardCore to be set to LOCK_FREE again, as it is now free, but it stays at 0, due to:

if (--s_nGuardAcquireCount)
{
	AtomicSet (&s_nGuardCore, LOCK_FREE);
}

I think that is a bug, it should be:

if (--s_nGuardAcquireCount ==0)
{
	AtomicSet (&s_nGuardCore, LOCK_FREE);
}

Thanks for all your work, I'm greatly enjoying diving deep into embedded RPI development.
I hope we'll soon get to see an implementation that also support RPI 5!

Kind regards,

Rene Barto

[rsta2]

Hi Rene, yes, that's a bug. Thanks for finding out the reason and for reporting it! I will prepare a hotfix release very soon. Thank you also for appreciating Circle. I will try to port Circle onto the RPi 5, but at least it will take time.

Rene

[rsta2]

The bug has been fixed in Circle 45.3.1, which is out now.

[renebarto]

Thanks for acting this quickly! Met vriendelijke groet / Kind regards, Rene Barto Op zo 8 okt. 2023 11:27 schreef Rene Stange ***@***.***>:

…

Closed #403 <#403> as resolved. — Reply to this email directly, view it on GitHub <#403>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAQY5NPPKCSUOZGE2EH7CWLX6JWXLAVCNFSM6AAAAAA5WAPIHCVHI2DSMVQWIX3LMV45UABEIRUXGY3VONZWS33OIV3GK3TUHI5E433UNFTGSY3BORUW63R3HA4TMNBSG4> . You are receiving this because you authored the thread.Message ID: ***@***.***>