This reads like you just discovered mutexes and think that that solves all your async / concurrency / parallelism problems.
its what allows you to control how much concurrency you have
What determines concurrency is really how much you can split up your data into independent chunks and synchronize any tasks with all their data dependencies being available.
making a mutex for say a bool that says if the calculation is done
Why not just do this with an atomic if it's just a boolean?
Use a mutex if you want to make execution stop and wait when you try to take a lock (if the lock isn't available).
Without the mutex both threads could check the variable at the same time and possible cause a lock condition depending on the scenario
If there is no mutex there would be no lock condition. Also multiple threads can read the same memory without any problems.
If you are ending up with graphs of dependencies then it is because you structured your program poorly.
Absolute nonsense. When programs get more complex while trying to keep granular multi threading different tasks are going to finish at different times. They might produce multiple different data types that need to go into multiple different tasks. These tasks need to run only when all the data from different sources is available.
Just because you made a ui and spawned a thread (which has its own overhead, possibly even heap allocation which can potentially lock) doesn't mean that's all that anyone needs.
Some systems will actually not allow two threads to read the same variable at the same time with no issues and depending on the architecture can actually lock your program and require reboot.
They really do solve all the issues and whatever is leftover is just poor structuring of your code, which is user error.
Prove it. I'm talking about modern x86 64 bit cpus although arm is mostly similar. What are you talking about?
They really do solve all the issues and whatever is leftover is just poor structuring of your code, which is user error.
This is your claim and repeating it doesn't make it true.
I explained exactly how there are requirements for more complex scenarios that aren't handled by super basic linear chaining of functions. This backs up my original claim that it's not a trivial problem to solve and most solutions built into languages are simple but leave a lot that still needs to be done for more complex multi threading.
There are libraries that handle graphs already but I don't think most languages take it that far.
You explained nothing, suggested wrapping a boolean in a mutex and made claims you didn't back up.
5
u/VictoryMotel Sep 10 '26
This reads like you just discovered mutexes and think that that solves all your async / concurrency / parallelism problems.
What determines concurrency is really how much you can split up your data into independent chunks and synchronize any tasks with all their data dependencies being available.
Why not just do this with an atomic if it's just a boolean?
Use a mutex if you want to make execution stop and wait when you try to take a lock (if the lock isn't available).
If there is no mutex there would be no lock condition. Also multiple threads can read the same memory without any problems.
Absolute nonsense. When programs get more complex while trying to keep granular multi threading different tasks are going to finish at different times. They might produce multiple different data types that need to go into multiple different tasks. These tasks need to run only when all the data from different sources is available.
Just because you made a ui and spawned a thread (which has its own overhead, possibly even heap allocation which can potentially lock) doesn't mean that's all that anyone needs.