Greetings Moritz,
I appreciate the elaboration response from you.
Yes, even if it did not come across in my prior question, I had the correct
posture in my thoughts.
Perhaps way back when Object Rexx first needed Semaphore and Mutex Semaphore
interfaces, C++ did not have suitable built-in, and now C++ has.
Moritz Hoffmann wrote:
It sounds convincing, but I also want to make sure we don't accidentallly break
parts of ooRexx.
Of course!!!
I am thankful,
Michael
Moritz Hoffmann wrote:
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]
<mailto:[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]> <mailto:[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]>
<mailto:[email protected] <mailto:[email protected]>>
> https://lists.sourceforge.net/lists/listinfo/oorexx-devel
>
>
>
> --
> Moritz Hoffmann;
> http://antiguru.de/
>
>
> _______________________________________________
> Oorexx-devel mailing list
> [email protected]
<mailto:[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]
<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
