A bit multi thread untested idea(RWR Lock), a bit off topic.

[YagaoDirac]

UPDATE:
I rewrite the test with unsafe rust. It doesn't pass the test. But the 1st test passed. I wrote 2 pseudo threads in a single thread environment for the 1st test. It's confusing.
I think I can draw a conclusion that in rust, volatile op doesn't make sure a read is blocked by a write.

https://github.com/YagaoDirac/RWR-Lock/blob/main/RWR%20lock.txt
Let me paste it here so you guys don't have to click the link.
I don't know if people are already using this.
If this is a bit too offtopic, I apologize.

I just found this:

Race Conditions and How to Prevent Them - A Look at Dekker's Algorithm:
by Spanning Tree
https://www.youtube.com/watch?v=MqnpIwN7dz0

In the video, the Dekker's Algo is explained.
I have 2 questions,
1, which thread is responsible for modifying the turn indicator?
2, how to scale this also to cases with more than 2 thread?
These 2 questions are related mutually.
Basically, I guess, in the Dekker's algo, when a thread quits the critical zone, it modifies the turn indicator, before it turn off its own light(or flag or any name I don't care). It means the indicator is also in the critical zone. But what happens if 3 threads are all trying to get in. I mean, how can the quiting thread determing the next thread?
Let's say, thread A is quiting, it set the turn indicator to B, but B is absent, while thread C is waiting.

I invented something similar recently, but I didn't test it. I'm very likely to find that people already invented my idea a long time ago. But before I find it, let me call my idea RWR lock, which is short for Read-Write-Read Lock.
The rule is, every thread has 1 flag(or light or anything). The flag starts unset. Every thread know where flags of other threads are.
Again, all flags start unset.
When a thread tried to access the critical zone, it does this:
Read flags of all other threads,
If any is/are set, then fail, it can retry immediately or later.
If all is/are unset, set up its own flag.
Read flags of all other threads again,
If any is/are set, then fail, unset its own flag. it can retry immediately or later.
If all is/are unset, succeed, access the critical zone.
When quit the critical zone, unset its own flag.

[DyXel]

This indeed seems quite off-topic to Cpp2, but I guess I could give you some answers:

how can the quiting thread determing the next thread?

This is entirely up to you; You define how you want to do your scheduling, the simplest one being a round-robin.

Let's say, thread A is quiting, it set the turn indicator to B, but B is absent, while thread C is waiting.

As said in the video, if no other light is ON, then thread C is free to go in even if B is absent (if its absent then it means that its light couldn't possibly be ON).

Anyways, I want to point out that this is very very low level stuff, and as a reminder, you need to use atomics and/or mutexes to do these kind of operations within the language (reading or writing naked flags/values/whatever is UB). Or use the other higher-level constructs that C++ provides (async, futures, etc.). If you want to learn about multi-threading and the memory model in the context of the language, I recommend Herb Sutter's "Atomic<> Weapons" talk, it is pretty good and still actual I believe despite its age.

[YagaoDirac]

Hi. Thanks for

if no other light is ON, then thread C is free to go in even if B is absent (if its absent then it means that its light couldn't possibly be ON).

I'll update my doc a bit.
Thanks for recommend all the well developped multi thread tools. I know them. This new idea is meant to use non of them. I'm still testing it.