I've come across a problem in the "reentrantLocking.ino" example. Running it on an esp32 causes a near dealock situation.
The spinlock() method never gets a "free lock". Trying to wait for the provided iterations period (0xFFFFFFFFUL) makes the sketch block for a very long time ...
Changing 0xFFFFFFFFUL to a much lower value resolves the blocking situation of course.
But, I dont understand yet why "if (tm_internal::atomicSwapBool(&locked, false, true))" never comes truecin this special situation ... I need more research on that.
Details:
esp32: Terminal output
ets Jun 8 2016 00:22:57
rst:0x1 (POWERON_RESET),boot:0x13 (SPI_FAST_FLASH_BOOT)
configsip: 0, SPIWP:0xee
clk_drv:0x00,q_drv:0x00,d_drv:0x00,cs0_drv:0x00,hd_drv:0x00,wp_drv:0x00
mode:DIO, clock div:1
load:0x3fff0018,len:4
load:0x3fff001c,len:1216
ho 0 tail 12 room 4
load:0x40078000,len:10944
load:0x40080400,len:6388
entry 0x400806b4
276 Running inner task, before lock =0
276 locked synchronously, count=1
276 in nested function, lock count=2
276 Synchronous task done=100
527 Running inner task, before lock =0
527 locked synchronously, count=1
527 in nested function, lock count=2
527 Synchronous task done=200
778 Running inner task, before lock =0
778 locked synchronously, count=1
778 in nested function, lock count=2
778 Synchronous task done=300
1026 Before try lock, count=0
1026 We need to do async lock=0
1026 - got the lock=1
1029 Running inner task, before lock =1
The problem starts here (reentrantLocking.ino) with the new TaskMgrLock:
...
taskManager.scheduleFixedRate(250, [] {
log("Running inner task, before lock ", myLock.getLockCount());
// take the lock
TaskMgrLock locker(myLock);
log("locked synchronously, count", myLock.getLockCount());
nestedFunction(); ...
SimpleSpinLock,h
/**
Take the lock waiting the longest possible time for it to become available.
*/
void lock() {
spinLock(0xFFFFFFFFUL);
}
SimpleSpinlock.ccp
...
if (tm_internal::atomicSwapBool(&locked, false, true)) { >> doesn't come true
...
Good evening Dave,
I've come across a problem in the "reentrantLocking.ino" example. Running it on an esp32 causes a near dealock situation. The spinlock() method never gets a "free lock". Trying to wait for the provided iterations period (0xFFFFFFFFUL) makes the sketch block for a very long time ...
Changing 0xFFFFFFFFUL to a much lower value resolves the blocking situation of course. But, I dont understand yet why "if (tm_internal::atomicSwapBool(&locked, false, true))" never comes truecin this special situation ... I need more research on that.
Details:
esp32: Terminal output ets Jun 8 2016 00:22:57 rst:0x1 (POWERON_RESET),boot:0x13 (SPI_FAST_FLASH_BOOT) configsip: 0, SPIWP:0xee clk_drv:0x00,q_drv:0x00,d_drv:0x00,cs0_drv:0x00,hd_drv:0x00,wp_drv:0x00 mode:DIO, clock div:1 load:0x3fff0018,len:4 load:0x3fff001c,len:1216 ho 0 tail 12 room 4 load:0x40078000,len:10944 load:0x40080400,len:6388 entry 0x400806b4 276 Running inner task, before lock =0 276 locked synchronously, count=1 276 in nested function, lock count=2 276 Synchronous task done=100 527 Running inner task, before lock =0 527 locked synchronously, count=1 527 in nested function, lock count=2 527 Synchronous task done=200 778 Running inner task, before lock =0 778 locked synchronously, count=1 778 in nested function, lock count=2 778 Synchronous task done=300 1026 Before try lock, count=0 1026 We need to do async lock=0 1026 - got the lock=1 1029 Running inner task, before lock =1
The problem starts here (reentrantLocking.ino) with the new TaskMgrLock: ... taskManager.scheduleFixedRate(250, [] { log("Running inner task, before lock ", myLock.getLockCount()); // take the lock TaskMgrLock locker(myLock);
log("locked synchronously, count", myLock.getLockCount()); nestedFunction(); ...
SimpleSpinLock,h /**
SimpleSpinlock.ccp ... if (tm_internal::atomicSwapBool(&locked, false, true)) { >> doesn't come true ...