It's not a semaphore

[hellmutbrudny]

Hi @IWILZ,
sorry to say that but your library doesn't synchronize like one would expect from "real semaphores". This is just two simple flags wrapped in class. It may work in your example because you use two separate buffers for both cores but in case of a single resource race (ex. both cores want to write to the same place in memory) it will fail.

If it works for you then ok but maybe add a proper statement in readme? Because now it may mislead some other users.

If you would like me to explain it deeper then don't hesitate to contact me.

[IWILZ]

First of all thank you for your opinion and your contribute @hellmutbrudny and let me also excuse me for my bad english.
I think to understand your point of view, but for me a "semaphore" is "a variable or abstract data type used to control access to a common resource by multiple threads" (as defined in https://en.wikipedia.org/wiki/Semaphore_(programming)).
So IMHO, concording with the previous definition, _full0 and _full1 are two semaphores that controls 2 shared resources (buffers) also if they are "unidirectional" (but this is not excluded by the definition).
Anyway yes, each buffer is one-way and for this reason i update the readme of my little project to explain better this characteristic and thank you again for your contribute and of course all this applies barring errors or oversights ;)

[hellmutbrudny]

Hi @IWILZ,

No worries, for me too English is not the first language ;).

Yes, I'm referring to the same definition of semaphore. What your implementation lacks is "mutual exclusion". It is mentioned on this wiki page you linked but quite scarcely. You can find it in following quote:
If the implementation does not ensure atomicity of the increment, decrement and comparison operations, then there is a risk of increments or decrements being forgotten, or of the semaphore value becoming negative.
"Atomicity" is the keyword here.

So, as I mentioned before, your example works as there is no real competing for the resources as you have only one writer and one reader for each queue. In such a case you don't need to worry about that two cores will try to acquire semaphore for writing in the same time. In other scenarios that may not work. But synchronization of concurrent processes is quite a complicated subject in total. You can start reading more there:
https://en.wikipedia.org/wiki/Mutual_exclusion
https://en.wikipedia.org/wiki/Test-and-set

For my projects on Pico it's enough to use core library mutex. I guess it's enough for most of cases as we have only two cores/threads. I use my own wrapper class for that:
https://raw.githubusercontent.com/hellmutbrudny/ArduinoLibs/main/PicoSyncZone/PicoSyncZone.h

And for the last: if your implementation works for you then it's ok. Just be aware that it's not enough for general purpose semaphore. And because of this: https://www.hackster.io/iwilz/picosem-a-raspberry-multi-tasking-under-arduino-framework-bc2d80 it may reach and mislead other users ;).