> So are the two call styles sort of equivalent, just that the one style causes the synchronization primitives, and the suggested style does not cause them?
Not quite; it isn't the call style that causes the problems and both behave the same at runtime. What I meant is that ooRexx ships its own SysMutex and SysSemaphore classes, which are thin wrappers around the OS APIs. I guess back when the code was written, there was no standard API available, but one exists now. The synchronization happens either way, the difference is what the wrappers guarantee. Specifically, the bugs weren't caused by high-level hand-rolling, but came from specific properties of the wrapper: * SysMutex carried a created flag, but its initialization wasn't synchronized between constructing the ELF object, causing it to override the created flag. This causes [1] where the ResourceSection was effectively guarding nothing. * request() returns a bool that we seem to ignore, and this caused silent lock failures. The equivalent standard APIs cannot fail silently. * volatile was used as a memory barrier, but doesn't provide the guarantees the code needs. It doesn't prevent reordering or load/store consistency, it only instructs the compiler to load from memory on each access. For mutexes, the standard APIs seem like a clean drop-in replacement. Claude points out some additional considerations where I can't judge the accuracy because I have no experience with Windows APIs. - ooRexx's mutexes are recursive (PTHREAD_MUTEX_RECURSIVE) and the code relies on the nesting, so it'd be std::recursive_mutex. Note that std::recursive_mutex's constructor is not constexpr, so it does not inherit the immunity in point 1 — you'd still want function-local statics, which is what I did on the branch. - On Windows, SysMutex::request() doesn't just wait. waitHandle() pumps the message queue via MsgWaitForMultipleObjects/PeekMessage unless bypassMessageLoop is set, so threads with window procedures don't deadlock the UI. std::mutex will not do that, and ooDialog depends on it. A blind swap would change that behaviour. - SysSemaphore isn't a semaphore in the standard sense — it's a manual-reset event with post/wait/reset/posted. The equivalent is std::condition_variable plus a flag, which is a rewrite rather than a swap. (std::counting_semaphore is C++20 and different semantics.) It sounds convincing, but I also want to make sure we don't accidentallly break parts of ooRexx. M [1] https://sourceforge.net/p/oorexx/bugs/2078/ On Sun, Jul 26, 2026 at 4:45 PM Michael Lueck <[email protected]> wrote: > Greetings Moritz, > > Yes, excellent leverage use of Claude Code! > > > You said: > > > Some of the bugs are caused by ooRexx implementing synchronization > primitives itself, and it seems we might want to switch to the ones in the > stdlib instead. > > > > So are the two call styles sort of equivalent, just that the one style > causes the synchronization primitives, and the suggested style does not > cause them? > > I am thankful, > Michael > > > > Moritz Hoffmann wrote: > > Patches are on GitHub: > > > > > https://github.com/ooRexx/ooRexx/compare/master...antiguru:ooRexx:concurrency-dispatch-fixes > > > > I can commit them to the SVN tree; easier for me to develop on GitHub. > > > > M > > > > On Sun, Jul 26, 2026 at 3:10 PM Rony G. Flatscher < > [email protected] <mailto:[email protected]>> wrote: > > > > Hi Moritz, > > > > On 25.07.2026 23:48, Moritz Hoffmann wrote: > > > I found a bunch of memory corruption bugs (or, really, Claude > Code found them). I captured the > > > diagnosis in bug reports in SF, and I can post patches if there's > interest. Some of the bugs are > > > caused by ooRexx implementing synchronization primitives itself, > and it seems we might want to > > > switch to the ones in the stdlib instead. > > > > *WOW*! > > > > Please, post the patches that fix these subtle problems that yield > the reported subtle bugs! > > > > Personally, I would also think that switching the "private" > synchronization primitives to the stdlib > > ones would be sensible, as long as these can be used on all > platforms (Windows, Linux, macOS). > > > > Just my two cents. > > > > Best regards > > > > ---rony > > > > > > > > > > _______________________________________________ > > Oorexx-devel mailing list > > [email protected] <mailto: > [email protected]> > > https://lists.sourceforge.net/lists/listinfo/oorexx-devel > > > > > > > > -- > > Moritz Hoffmann; > > http://antiguru.de/ > > > > > > _______________________________________________ > > Oorexx-devel mailing list > > [email protected] > > https://lists.sourceforge.net/lists/listinfo/oorexx-devel > > > > > -- > Michael Lueck > Lueck Data Systems > http://www.lueckdatasystems.com/ > > > _______________________________________________ > Oorexx-devel mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/oorexx-devel > -- Moritz Hoffmann; http://antiguru.de/
_______________________________________________ Oorexx-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/oorexx-devel
