Date: Wed, 31 May 2023 19:58:09 -0400
- Ok so at that level 90% of the low-level race-conditions are already solved;
- The container::empty() could return a temporary object that can be converted to a boolean but also locks the internal recursive mutex;
I assume here the temporary object will last for the duration of the condition but I will double-check that later. If not then the rules can always be extended.
If that still doesn't work for some reason then I'll just automate it with C++ Superset. Very simple.
Thanks,
--
 |
| |||||||
 Le message ci-dessus, ainsi que les documents l'accompagnant, sont destinés uniquement aux personnes identifiées et peuvent contenir des informations privilégiées, confidentielles ou ne pouvant être divulguées. Si vous avez reçu ce message par erreur, veuillez le détruire.This communication (and/or the attachments) is intended for named recipients only and may contain privileged or confidential information which is not to be disclosed. If you received this communication by mistake please destroy all copies. | ||||||||
On May 31, 2023, at 6:35 PM, Thiago Macieira <thiago_at_[hidden]> wrote:
On Wednesday, 31 May 2023 15:29:43 PDT Phil Bouchard wrote:The solution is to eliminate the probability race-conditions happen atlow-level layers so the programmer can focus on higher levelfunctionalities and algorithms.If the programmer can't write proper high-level algorithms then that'sanother story.
But if the programmer can write high-level algorithms, the low-level silent
locking you're proposing is, at best, overhead. At worst, it's counter-
productive causing deadlocks that the programmer needs to workaround.
As a quick example: how would you write the code for "if the list is empty,
append value 1" (remember: multiple threads will be running this code).
--
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
Software Architect - Intel DCAI Cloud Engineering
Received on 2023-05-31 23:58:21