|
Quote: I am getting true concurrency from the looks of it.
Cool 
Quote: I'm about to release a new article that builds on the stuff i recently wrote, only (hopefully) not specific to the ESP32 this time, and has more stuff like threads and thread pooling added to it
I'll read it with great interest 
Espen Harlinn
Senior Architect - Ulriken Consulting AS
The competent programmer is fully aware of the strictly limited size of his own skull; therefore he approaches the programming task in full humility, and among other things he avoids clever tricks like the plague.Edsger W.Dijkstra
|
|
|
|
|
|
Quote: Here's that article.
Thanks, I will read it 
Espen Harlinn
Senior Architect - Ulriken Consulting AS
The competent programmer is fully aware of the strictly limited size of his own skull; therefore he approaches the programming task in full humility, and among other things he avoids clever tricks like the plague.Edsger W.Dijkstra
|
|
|
|
|
Espen Harlinn wrote: If I understand the docs[^] correctly, FreeRTOS is quite limited with regard to multi-core support
ESP32 uses a modified version of FreeRTOS[^] with added symmetric multiprocessing support.
|
|
|
|
|
Oh, is that what that is?
I better put some conditional compiles in my code.
Real programmers use butterflies
|
|
|
|
|
Look up "lock convoying". It's a well-known problem with lock-based multithreading.
Freedom is the freedom to say that two plus two make four. If that is granted, all else follows.
-- 6079 Smith W.
|
|
|
|
|
I'm not explicitly using locks in my own test code, though I did notice that Serial.println() appears to be atomic.
Real programmers use butterflies
|
|
|
|
|
You may find that other parts of the O/S use locks.
For example, I/O in blocks larger than the maximum supported by the hardware may be divided into blocks which are serialised using some sort of queue or lock. It's not the way you'do do it in Windows or Linux, but it works.
Freedom is the freedom to say that two plus two make four. If that is granted, all else follows.
-- 6079 Smith W.
|
|
|
|
|
Yeah. That's what I was implying when I said Serial.print/println seemed atomic - other stuff locks.
Real programmers use butterflies
|
|
|
|
|
Use the overload that let's you specify a bool to indicate whether execution should be non-deterministic (default is false) 
|
|
|
|
|
This is the predictability equivalent of a "Heisenbug".
|
|
|
|
|
How could instructions be non-deterministic when they share the same clock (even on different cores) ? Even random numbers generators are determinitic. I think that the only way to introduce some "chance" in a piece of code is to get information from "outside" : wait for something from a mechanical disk, a keyboard, an other computer...
|
|
|
|
|
I'm writing to an external serial port, and it waits for the writes to complete. That should give it some amount of non-determinism.
Real programmers use butterflies
|
|
|
|
|
Just remember the following and you'll do fine with multi-threading:
Variables and constants aren't.
|
|
|
|
|
I'm an admittedly rookie programmer who hasn't done much with multithreading. But wouldn't a Real Time Operating system always do things in the same order? Much like a processor on a PLC? I'm here to learn, so if you have the time to answer that would be great. 
|
|
|
|
|
Not if there's I/O or something involved, but otherwise, yes, it "probably" will.
The reason I say probably is because when you're dealing with multiple cores, they don't run in lockstep with one another. There's a small amount of non-determinism just in the fact that the cores keep their own schedulers and may not have started at precisely the same moment nor even work together***
*** they might synchronize with each other - it's a FreeRTOS-ESP32variant implementation detail I haven't looked into.
But that aside, there's also the issue of I/O, which when dealing with an external device, can introduce non-determinism.
In my code, I'm outputting to a serial UART, that's connected through an FTDI built bus/USB-bridge controller to a windows PC.
Any latency introduced by the PC will ripple back to the thread that's running waiting on I/O.
Real programmers use butterflies
|
|
|
|
|
|
What scheduling algorithm is being used? IIRC, FreeRTOS has multiple scheduling algorithms you can choose between, which might affect the amount of non-determinism?
Java, Basic, who cares - it's all a bunch of tree-hugging hippy cr*p
|
|
|
|
|
Hmm. The one I'm using is a variant ported to the ESP32 to use the ESP-IDF, by Espressif.
Their forums, and the FreeRTOS documentation I've encountered online both suggest that round robin is used for any thread created on the same priority level on the same scheduler (core)
This leads to starvation. The forums warn of it particularly, but so does setting different priorities, just for slightly different reasons.
There's no "salting" done in their scheduler according to any of the documentation I've encountered.
Real programmers use butterflies
|
|
|
|
|
I was under the impression that round robin scheduling would guarantee equal time for pre-emptive tasks with the same priority (presuming no higher priority task preempts them), which should mean no starvation. Guess I was under the wrong impression.
Java, Basic, who cares - it's all a bunch of tree-hugging hippy cr*p
|
|
|
|
|
In the case where thread A and thread B operate at the same priority, everything works until we start looking at who to unblock. It will always unblock the next thread in the round robin list. if thread A is coded where it sleeps twice for every time thread B sleeps once, I think it will lead to one of them being starved. I'm not entirely confident in that without testing it, but it's easy for me to starve a thread in the wild on this OS.
If it were me i would have stored the machine tick based timestamp on the last time the thread was unsuspended. all priorities considered equal, i would use that to determine which to wake up next, and then if further disambiguation was necessary (doubtful) it could round robin, but i don't think that's even necessary.
Real programmers use butterflies
modified 2-Mar-21 14:56pm.
|
|
|
|
|
embar.k.adero’s spate of complaints got me wondering - what is the average age of cp users?
".45 ACP - because shooting twice is just silly" - JSOP, 2010
-----
You can never have too much ammo - unless you're swimming, or on fire. - JSOP, 2010
-----
When you pry the gun from my cold dead hands, be careful - the barrel will be very hot. - JSOP, 2013
|
|
|
|
|
I'm 16.
Have been for almost thirty years.
Bastard Programmer from Hell 
"If you just follow the bacon Eddy, wherever it leads you, then you won't have to think about politics." -- Some Bell.
|
|
|
|
|
My dad was 29 as far back as I can remember.
".45 ACP - because shooting twice is just silly" - JSOP, 2010
-----
You can never have too much ammo - unless you're swimming, or on fire. - JSOP, 2010
-----
When you pry the gun from my cold dead hands, be careful - the barrel will be very hot. - JSOP, 2013
|
|
|
|
|
About 4 years ago, I got my mother a 50th anniversary card for her 29th birthday.
Software Zen: delete this;
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
