On 11/18/2023 5:20 PM, Pavel wrote:
> Chris M. Thomasson wrote:
>> On 11/18/2023 1:47 PM, Scott Lurndal wrote:
>>> "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> writes:
>>>> On 11/18/2023 9:53 AM, Pavel wrote:
>>>>> Bonita Montero wrote:
>>>>>> Am 18.11.2023 um 03:16 schrieb Pavel:
>>>>>>
>>>>>>> There is no system call in UNIX to wait for many conditions to be
>>>>>>> met
>>>>>>> at once; but I do not see why it would be useful.
>>>>>>
>>>>>> poll() and wait() wait for at least one condition to be met.
>>>>> what does it have to do with what I wrote?
>>>>>
>>>>> Again, what a system call that waits for many conditions to be met at
>>>>> once can be useful for?
>>>>
>>>> select?
>>>
>>> I took Pavel to mean 'wait for all conditions to be true' rather than
>>> 'wait for one or more conditions to be true'.
>>>
>>
>> Ahhh. I missed that. Sorry everybody! ;^o
> NP, Scott is correct, this was about "wait for many conditions to be met
> at once" that Bonita missed on Linux for some reason I still cannot get
> or relate to.

It guess Bonita does not know that a predicate for a condition variable
can contain many conditions.

Am 20.11.2023 um 21:18 schrieb Chris M. Thomasson:

> Did you read that article on MSDN as well? Iirc, its around 20 years old.

Has WFMO ever changed ?

On Sat, 18 Nov 2023 20:29:51 -0000 (UTC)
Kaz Kylheku <864-117-4973@kylheku.com> wrote:

> On 2023-11-18, Scott Lurndal <scott@slp53.sl.home> wrote:
> > Pavel <pauldontspamtolk@removeyourself.dontspam.yahoo> writes:
> >>Bonita Montero wrote:
> >>> Am 18.11.2023 um 03:16 schrieb Pavel:
> >>>
> >>>> There is no system call in UNIX to wait for many conditions to
> >>>> be met at once; but I do not see why it would be useful.
> >>>
> >>> poll() and wait() wait for at least one condition to be met.
> >>what does it have to do with what I wrote?
> >>
> >>Again, what a system call that waits for many conditions to be met
> >>at once can be useful for?
> >
> > Rendezvous.
> >
> > e.g. pthread_barrier_wait.
>
> Also this:
>
> while (!this_condition() && !that_condition() &&
> !other_condition()) pthread_cond_wait(&cond, &mutex);
>
> One condition variable can be used to wait for any subset of the
> actual conditions over the shared variables protected by the mutex.
>
> When I switched to a Win32 development job in the mid 1990's, it
> amused me that Win32 had all these stupid things like
> WaitForMultipleObjects (with a weird 64 limit), instead of just
> providing condition variables.
>

1. WaitForMultipleObjects() can wait on any mix of objects
2. More importantly, it can wait on wake up events originated both
inside the process and outside.

> Today, Microsoft provides condition variables.
>

Which, I would guess, never used by 99.9% of programs that were not
ported to Windows from some other platform.

> Modules of a large program should use callbacks to notify that
> something is ready. That's the most flexible API. The caller can
> build proper asynchronous control flows around that, or bind the
> callback to some signaling object according to how they see fit.
>
> Say I have a module that works with three other modules that can
> spontaneously make some condition ready. If they all provide a
> callback, I can set a flag in the callback and broadcast or signal a
> condition variable. Then I can have threads wait for all three
> things to be ready, or any one of the three things.
>

On 11/23/2023 3:14 PM, Michael S wrote:
> On Sat, 18 Nov 2023 20:29:51 -0000 (UTC)
> Kaz Kylheku <864-117-4973@kylheku.com> wrote:
>
>> On 2023-11-18, Scott Lurndal <scott@slp53.sl.home> wrote:
>>> Pavel <pauldontspamtolk@removeyourself.dontspam.yahoo> writes:
>>>> Bonita Montero wrote:
>>>>> Am 18.11.2023 um 03:16 schrieb Pavel:
>>>>>
>>>>>> There is no system call in UNIX to wait for many conditions to
>>>>>> be met at once; but I do not see why it would be useful.
>>>>>
>>>>> poll() and wait() wait for at least one condition to be met.
>>>> what does it have to do with what I wrote?
>>>>
>>>> Again, what a system call that waits for many conditions to be met
>>>> at once can be useful for?
>>>
>>> Rendezvous.
>>>
>>> e.g. pthread_barrier_wait.
>>
>> Also this:
>>
>> while (!this_condition() && !that_condition() &&
>> !other_condition()) pthread_cond_wait(&cond, &mutex);
>>
>> One condition variable can be used to wait for any subset of the
>> actual conditions over the shared variables protected by the mutex.
>>
>> When I switched to a Win32 development job in the mid 1990's, it
>> amused me that Win32 had all these stupid things like
>> WaitForMultipleObjects (with a weird 64 limit), instead of just
>> providing condition variables.
>>
>
> 1. WaitForMultipleObjects() can wait on any mix of objects
> 2. More importantly, it can wait on wake up events originated both
> inside the process and outside.
>
>
>> Today, Microsoft provides condition variables.
>>
>
> Which, I would guess, never used by 99.9% of programs that were not
> ported to Windows from some other platform.

Fwiw, check this out:

https://sourceware.org/pthreads-win32/

;^)

>
>> Modules of a large program should use callbacks to notify that
>> something is ready. That's the most flexible API. The caller can
>> build proper asynchronous control flows around that, or bind the
>> callback to some signaling object according to how they see fit.
>>
>> Say I have a module that works with three other modules that can
>> spontaneously make some condition ready. If they all provide a
>> callback, I can set a flag in the callback and broadcast or signal a
>> condition variable. Then I can have threads wait for all three
>> things to be ready, or any one of the three things.
>>
>
>

On 11/21/2023 1:25 AM, Bonita Montero wrote:
> Am 20.11.2023 um 21:18 schrieb Chris M. Thomasson:
>
>> Did you read that article on MSDN as well? Iirc, its around 20 years old.
>
> Has WFMO ever changed ?
>

No, I don't think so.. The interesting aspect was about trying to avoid
starvation the the wait array wrt the IOCP vs Event contest. So, we were
advised to randomize and/or shift the positions wrt the event side wrt WFMO.

Am 24.11.2023 um 06:38 schrieb Chris M. Thomasson:

> No, I don't think so.. The interesting aspect was about trying to avoid
> starvation the the wait array wrt the IOCP vs Event contest. So, we were
> advised to randomize and/or shift the positions wrt the event side wrt
> WFMO.

You officially can't wait for an IOCP handle with WFMO, although this
actually works with my Windows 11 computer. MS should document that and
make a statement since which Windows version this actually works. This
isn't a strong requirement but it would be nice to wait for IOCPs with
WFMO in some cases.

Am 24.11.2023 um 06:35 schrieb Chris M. Thomasson:

> On 11/23/2023 3:14 PM, Michael S wrote:

>> Which, I would guess, never used by 99.9% of programs that were not
>> ported to Windows from some other platform.

> Fwiw, check this out:
> https://sourceware.org/pthreads-win32/

Am 24.11.2023 um 06:35 schrieb Chris M. Thomasson:

That's an unnecessary discussion for a C++ programmer since the RAII-ish
mutexes and condition variables since C++11 are more convenient to use.

On 11/23/2023 11:59 PM, Bonita Montero wrote:
> Am 24.11.2023 um 06:35 schrieb Chris M. Thomasson:
>
>> On 11/23/2023 3:14 PM, Michael S wrote:
>
>>> Which, I would guess, never used by 99.9% of programs that were not
>>> ported to Windows from some other platform.
>
>> Fwiw, check this out:
>> https://sourceware.org/pthreads-win32/
>
> Am 24.11.2023 um 06:35 schrieb Chris M. Thomasson:
>
> That's an unnecessary discussion for a C++ programmer since the RAII-ish
> mutexes and condition variables since C++11 are more convenient to use.
>
>
>
>

Have you ever wrapped up a C API in C++ using RAII before?

On 11/23/2023 11:56 PM, Bonita Montero wrote:
> Am 24.11.2023 um 06:38 schrieb Chris M. Thomasson:
>
>> No, I don't think so.. The interesting aspect was about trying to
>> avoid starvation the the wait array wrt the IOCP vs Event contest. So,
>> we were advised to randomize and/or shift the positions wrt the event
>> side wrt WFMO.
>
> You officially can't wait for an IOCP handle with WFMO, although this
> actually works with my Windows 11 computer. MS should document that and
> make a statement since which Windows version this actually works. This
> isn't a strong requirement but it would be nice to wait for IOCPs with
> WFMO in some cases.
>

Humm... You should be using:

https://learn.microsoft.com/en-us/windows/win32/fileio/getqueuedcompletionstatusex-func

Am 24.11.2023 um 10:17 schrieb Chris M. Thomasson:

> Have you ever wrapped up a C API in C++ using RAII before?

Sometimes, but mostly I don't write a dedicated class for that but use
my own invoke_on_destruct class which is similar to the experimental#
scope_exit: https://en.cppreference.com/w/cpp/experimental/scope_exit

"Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> writes:
>On 11/23/2023 11:59 PM, Bonita Montero wrote:
>> Am 24.11.2023 um 06:35 schrieb Chris M. Thomasson:
>>
>>> On 11/23/2023 3:14 PM, Michael S wrote:
>>
>>>> Which, I would guess, never used by 99.9% of programs that were not
>>>> ported to Windows from some other platform.
>>
>>> Fwiw, check this out:
>>> https://sourceware.org/pthreads-win32/
>>
>> Am 24.11.2023 um 06:35 schrieb Chris M. Thomasson:
>>
>> That's an unnecessary discussion for a C++ programmer since the RAII-ish
>> mutexes and condition variables since C++11 are more convenient to use.
>>
>>
>>
>>
>
>Have you ever wrapped up a C API in C++ using RAII before?

I generally consider using RAII for synchronization primitives
to be counterindicated. Amongst the reasons:
1) The critical sections usually end up being far to large
2) It makes reasoning about the synchronization code and
potential nested locking more difficult.

Am 24.11.2023 um 10:22 schrieb Chris M. Thomasson:
> On 11/23/2023 11:56 PM, Bonita Montero wrote:
>> Am 24.11.2023 um 06:38 schrieb Chris M. Thomasson:
>>
>>> No, I don't think so.. The interesting aspect was about trying to
>>> avoid starvation the the wait array wrt the IOCP vs Event contest.
>>> So, we were advised to randomize and/or shift the positions wrt the
>>> event side wrt WFMO.
>>
>> You officially can't wait for an IOCP handle with WFMO, although this
>> actually works with my Windows 11 computer. MS should document that and
>> make a statement since which Windows version this actually works. This
>> isn't a strong requirement but it would be nice to wait for IOCPs with
>> WFMO in some cases.
>>
>
> Humm... You should be using:
>
> https://learn.microsoft.com/en-us/windows/win32/fileio/getqueuedcompletionstatusex-func

Why do you think I don't know GetQueuedCompletionStatus() ?
I said that it would be nice to do a WFMO on a IOCP in addition to that.

On 2023-11-24, Scott Lurndal <scott@slp53.sl.home> wrote:
> "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> writes:
>>On 11/23/2023 11:59 PM, Bonita Montero wrote:
>>> Am 24.11.2023 um 06:35 schrieb Chris M. Thomasson:
>>>
>>>> On 11/23/2023 3:14 PM, Michael S wrote:
>>>
>>>>> Which, I would guess, never used by 99.9% of programs that were not
>>>>> ported to Windows from some other platform.
>>>
>>>> Fwiw, check this out:
>>>> https://sourceware.org/pthreads-win32/
>>>
>>> Am 24.11.2023 um 06:35 schrieb Chris M. Thomasson:
>>>
>>> That's an unnecessary discussion for a C++ programmer since the RAII-ish
>>> mutexes and condition variables since C++11 are more convenient to use.
>>>
>>>
>>>
>>>
>>
>>Have you ever wrapped up a C API in C++ using RAII before?
>
> I generally consider using RAII for synchronization primitives
> to be counterindicated. Amongst the reasons:
> 1) The critical sections usually end up being far to large

Use braces?

{
mutex_locker m(obj);

}

> 2) It makes reasoning about the synchronization code and
> potential nested locking more difficult.

It's just a syntactic sugar to avoid forgetting to unlock.

The thing is, you need a complementary unlocker to
avoid the nesting:

{
mutex_locker m(obj);

// ...

if (obj.situation()) {
mutex_unlocker u(obj); // temporarily give up mutex
other_obj.method(); // this can call us back again
}
}

--
TXR Programming Language: http://nongnu.org/txr
Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal
Mastodon: @Kazinator@mstdn.ca
NOTE: If you use Google Groups, I don't see you, unless you're whitelisted.

On 11/24/2023 10:33 AM, Kaz Kylheku wrote:
> On 2023-11-24, Scott Lurndal <scott@slp53.sl.home> wrote:
>> "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> writes:
>>> On 11/23/2023 11:59 PM, Bonita Montero wrote:
>>>> Am 24.11.2023 um 06:35 schrieb Chris M. Thomasson:
>>>>
>>>>> On 11/23/2023 3:14 PM, Michael S wrote:
>>>>
>>>>>> Which, I would guess, never used by 99.9% of programs that were not
>>>>>> ported to Windows from some other platform.
>>>>
>>>>> Fwiw, check this out:
>>>>> https://sourceware.org/pthreads-win32/
>>>>
>>>> Am 24.11.2023 um 06:35 schrieb Chris M. Thomasson:
>>>>
>>>> That's an unnecessary discussion for a C++ programmer since the RAII-ish
>>>> mutexes and condition variables since C++11 are more convenient to use.
>>>>
>>>>
>>>>
>>>>
>>>
>>> Have you ever wrapped up a C API in C++ using RAII before?
>>
>> I generally consider using RAII for synchronization primitives
>> to be counterindicated. Amongst the reasons:
>> 1) The critical sections usually end up being far to large
>
> Use braces?
>
> {
> mutex_locker m(obj);
>
>
> }

DING!!! :^)

>
>> 2) It makes reasoning about the synchronization code and
>> potential nested locking more difficult.
>
> It's just a syntactic sugar to avoid forgetting to unlock.
>
> The thing is, you need a complementary unlocker to
> avoid the nesting:
>
> {
> mutex_locker m(obj);
>
> // ...
>
> if (obj.situation()) {
> mutex_unlocker u(obj); // temporarily give up mutex
> other_obj.method(); // this can call us back again
> }
> }
>
>

:^)

On 11/24/2023 10:10 AM, Bonita Montero wrote:
> Am 24.11.2023 um 10:22 schrieb Chris M. Thomasson:
>> On 11/23/2023 11:56 PM, Bonita Montero wrote:
>>> Am 24.11.2023 um 06:38 schrieb Chris M. Thomasson:
>>>
>>>> No, I don't think so.. The interesting aspect was about trying to
>>>> avoid starvation the the wait array wrt the IOCP vs Event contest.
>>>> So, we were advised to randomize and/or shift the positions wrt the
>>>> event side wrt WFMO.
>>>
>>> You officially can't wait for an IOCP handle with WFMO, although this
>>> actually works with my Windows 11 computer. MS should document that and
>>> make a statement since which Windows version this actually works. This
>>> isn't a strong requirement but it would be nice to wait for IOCPs with
>>> WFMO in some cases.
>>>
>>
>> Humm... You should be using:
>>
>> https://learn.microsoft.com/en-us/windows/win32/fileio/getqueuedcompletionstatusex-func
>
> Why do you think I don't know GetQueuedCompletionStatus() ?

Btw, I said:

GetQueuedCompletionStatusEx

NOT

GetQueuedCompletionStatus

:^)

> I said that it would be nice to do a WFMO on a IOCP in addition to that.

How would that even work? You do not need to create an event per
connection in IOCP model. IOCP is a different model that is not
compatible with WFMO.

"Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> writes:
>On 11/24/2023 10:33 AM, Kaz Kylheku wrote:
>> On 2023-11-24, Scott Lurndal <scott@slp53.sl.home> wrote:
>>> "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> writes:
>>>> On 11/23/2023 11:59 PM, Bonita Montero wrote:
>>>>> Am 24.11.2023 um 06:35 schrieb Chris M. Thomasson:
>>>>>
>>>>>> On 11/23/2023 3:14 PM, Michael S wrote:
>>>>>
>>>>>>> Which, I would guess, never used by 99.9% of programs that were not
>>>>>>> ported to Windows from some other platform.
>>>>>
>>>>>> Fwiw, check this out:
>>>>>> https://sourceware.org/pthreads-win32/
>>>>>
>>>>> Am 24.11.2023 um 06:35 schrieb Chris M. Thomasson:
>>>>>
>>>>> That's an unnecessary discussion for a C++ programmer since the RAII-ish
>>>>> mutexes and condition variables since C++11 are more convenient to use.
>>>>>
>>>>>
>>>>>
>>>>>
>>>>
>>>> Have you ever wrapped up a C API in C++ using RAII before?
>>>
>>> I generally consider using RAII for synchronization primitives
>>> to be counterindicated. Amongst the reasons:
>>> 1) The critical sections usually end up being far to large
>>
>> Use braces?
>>
>> {
>> mutex_locker m(obj);
>>
>>
>> }
>
>DING!!! :^)

No, not really. It's not always that
easy, and sometimes programmers even use 'goto'.

That's certainly no more readable than

pthread_lock(obj);

do something

pthread_unlock(obj);

I'd argue the RAII solution is less readable.

On 11/24/2023 4:08 PM, Scott Lurndal wrote:
> "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> writes:
>> On 11/24/2023 10:33 AM, Kaz Kylheku wrote:
>>> On 2023-11-24, Scott Lurndal <scott@slp53.sl.home> wrote:
>>>> "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> writes:
>>>>> On 11/23/2023 11:59 PM, Bonita Montero wrote:
>>>>>> Am 24.11.2023 um 06:35 schrieb Chris M. Thomasson:
>>>>>>
>>>>>>> On 11/23/2023 3:14 PM, Michael S wrote:
>>>>>>
>>>>>>>> Which, I would guess, never used by 99.9% of programs that were not
>>>>>>>> ported to Windows from some other platform.
>>>>>>
>>>>>>> Fwiw, check this out:
>>>>>>> https://sourceware.org/pthreads-win32/
>>>>>>
>>>>>> Am 24.11.2023 um 06:35 schrieb Chris M. Thomasson:
>>>>>>
>>>>>> That's an unnecessary discussion for a C++ programmer since the RAII-ish
>>>>>> mutexes and condition variables since C++11 are more convenient to use.
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>> Have you ever wrapped up a C API in C++ using RAII before?
>>>>
>>>> I generally consider using RAII for synchronization primitives
>>>> to be counterindicated. Amongst the reasons:
>>>> 1) The critical sections usually end up being far to large
>>>
>>> Use braces?
>>>
>>> {
>>> mutex_locker m(obj);
>>>
>>>
>>> }
>>
>> DING!!! :^)
>
> No, not really. It's not always that
> easy, and sometimes programmers even use 'goto'.
>
> That's certainly no more readable than
>
> pthread_lock(obj);
>
> do something
>
> pthread_unlock(obj);
>
> I'd argue the RAII solution is less readable.

RAII can come in handy. I don't think its all that bad. Humm...
_______________________
{ mutex_raii_lock(my_lock);
} _______________________

vs:
_______________________
my_lock.lock();
my_lock.unlock();
_______________________

Btw, wrt C++, RAII tends to work rather well with exceptions... ;^)

Op 25.nov.2023 om 01:08 schreef Scott Lurndal:
> "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> writes:
>> On 11/24/2023 10:33 AM, Kaz Kylheku wrote:
>>> On 2023-11-24, Scott Lurndal <scott@slp53.sl.home> wrote:
>>>> "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> writes:
>>>>> On 11/23/2023 11:59 PM, Bonita Montero wrote:
>>>>>> Am 24.11.2023 um 06:35 schrieb Chris M. Thomasson:
>>>>>>
>>>>>>> On 11/23/2023 3:14 PM, Michael S wrote:
>>>>>>
>>>>>>>> Which, I would guess, never used by 99.9% of programs that were not
>>>>>>>> ported to Windows from some other platform.
>>>>>>
>>>>>>> Fwiw, check this out:
>>>>>>> https://sourceware.org/pthreads-win32/
>>>>>>
>>>>>> Am 24.11.2023 um 06:35 schrieb Chris M. Thomasson:
>>>>>>
>>>>>> That's an unnecessary discussion for a C++ programmer since the RAII-ish
>>>>>> mutexes and condition variables since C++11 are more convenient to use.
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>> Have you ever wrapped up a C API in C++ using RAII before?
>>>>
>>>> I generally consider using RAII for synchronization primitives
>>>> to be counterindicated. Amongst the reasons:
>>>> 1) The critical sections usually end up being far to large
>>>
>>> Use braces?
>>>
>>> {
>>> mutex_locker m(obj);
>>>
>>>
>>> }
>>
>> DING!!! :^)
>
> No, not really. It's not always that
> easy, and sometimes programmers even use 'goto'.
>
> That's certainly no more readable than
>
> pthread_lock(obj);
>
> do something
>
> pthread_unlock(obj);
>
> I'd argue the RAII solution is less readable.

In many cases it is not that simple.
It is more like:

{
mutex_locker m(obj);
do something
if (....) continue;
if (....) break;
if (...) return;
do something else
}

vs.:

pthread_lock(obj);
{
do something
if (...) {
pthread_unlock(obj);
continue;
}
if (...) {
pthread_unlock(obj);
break;
}
if (....) {
pthread_unlock(obj);
return;
}
do something else
} catch (...) {
pthread_unlock(obj);
throw;
}
pthread_unlock(obj);

Personally I find the first way more readable and easier to maintain.

Am 25.11.2023 um 00:43 schrieb Chris M. Thomasson:

> How would that even work? You do not need to create an event per
> connection in IOCP model. IOCP is a different model that is not
> compatible with WFMO.

You'd have to ask GQCS after you waited. Actually WFMO works
on a IOCP für my Windows 11 PC, but this isn't documented.

Am 24.11.2023 um 19:33 schrieb Kaz Kylheku:

> It's just a syntactic sugar to avoid forgetting to unlock ...

RAII is magnitudes more convenient and lass error-prone
than manual resource handling.

On 24/11/2023 19:33, Kaz Kylheku wrote:
> On 2023-11-24, Scott Lurndal <scott@slp53.sl.home> wrote:
>> "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> writes:
>>> On 11/23/2023 11:59 PM, Bonita Montero wrote:
>>>> Am 24.11.2023 um 06:35 schrieb Chris M. Thomasson:
>>>>
>>>>> On 11/23/2023 3:14 PM, Michael S wrote:
>>>>
>>>>>> Which, I would guess, never used by 99.9% of programs that were not
>>>>>> ported to Windows from some other platform.
>>>>
>>>>> Fwiw, check this out:
>>>>> https://sourceware.org/pthreads-win32/
>>>>
>>>> Am 24.11.2023 um 06:35 schrieb Chris M. Thomasson:
>>>>
>>>> That's an unnecessary discussion for a C++ programmer since the RAII-ish
>>>> mutexes and condition variables since C++11 are more convenient to use.
>>>>
>>>>
>>>>
>>>>
>>>
>>> Have you ever wrapped up a C API in C++ using RAII before?
>>
>> I generally consider using RAII for synchronization primitives
>> to be counterindicated. Amongst the reasons:
>> 1) The critical sections usually end up being far to large
>
> Use braces?

Yes.

>
> {
> mutex_locker m(obj);
>
>
> }
>
>> 2) It makes reasoning about the synchronization code and
>> potential nested locking more difficult.
>
> It's just a syntactic sugar to avoid forgetting to unlock.

That makes it sound like it is possible to use RAII locks to avoid
thinking too much, and that's a bad attitude. I would rather say that
RAII lockers can be useful to keep code clearer, and make the locked
section obvious with less clutter. It is still just as important to
think carefully about where the locks go!

>
> The thing is, you need a complementary unlocker to
> avoid the nesting:
>
> {
> mutex_locker m(obj);
>
> // ...
>
> if (obj.situation()) {
> mutex_unlocker u(obj); // temporarily give up mutex
> other_obj.method(); // this can call us back again
> }
> }
>
>

With unlockers, you are getting complicated again, and it's hard to
understand and reason about the locks. They can be useful, but rarely.

IME, RAII locks are sometimes a better choice, while other times free
lock and unlock functions are better. There is no "one size fits all"
answer.

"Fred. Zwarts" <F.Zwarts@HetNet.nl> writes:
>Op 25.nov.2023 om 01:08 schreef Scott Lurndal:
>> "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> writes:
>>> On 11/24/2023 10:33 AM, Kaz Kylheku wrote:
>>>> On 2023-11-24, Scott Lurndal <scott@slp53.sl.home> wrote:
>>>>> "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> writes:
>>>>>> On 11/23/2023 11:59 PM, Bonita Montero wrote:
>>>>>>> Am 24.11.2023 um 06:35 schrieb Chris M. Thomasson:
>>>>>>>
>>>>>>>> On 11/23/2023 3:14 PM, Michael S wrote:
>>>>>>>
>>>>>>>>> Which, I would guess, never used by 99.9% of programs that were not
>>>>>>>>> ported to Windows from some other platform.
>>>>>>>
>>>>>>>> Fwiw, check this out:
>>>>>>>> https://sourceware.org/pthreads-win32/
>>>>>>>
>>>>>>> Am 24.11.2023 um 06:35 schrieb Chris M. Thomasson:
>>>>>>>
>>>>>>> That's an unnecessary discussion for a C++ programmer since the RAII-ish
>>>>>>> mutexes and condition variables since C++11 are more convenient to use.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>> Have you ever wrapped up a C API in C++ using RAII before?
>>>>>
>>>>> I generally consider using RAII for synchronization primitives
>>>>> to be counterindicated. Amongst the reasons:
>>>>> 1) The critical sections usually end up being far to large
>>>>
>>>> Use braces?
>>>>
>>>> {
>>>> mutex_locker m(obj);
>>>>
>>>>
>>>> }
>>>
>>> DING!!! :^)
>>
>> No, not really. It's not always that
>> easy, and sometimes programmers even use 'goto'.
>>
>> That's certainly no more readable than
>>
>> pthread_lock(obj);
>>
>> do something
>>
>> pthread_unlock(obj);
>>
>> I'd argue the RAII solution is less readable.
>
>In many cases it is not that simple.
>It is more like:
>
> {
> mutex_locker m(obj);
> do something
> if (....) continue;
> if (....) break;
> if (...) return;
> do something else
> }
>
>vs.:
>
> pthread_lock(obj);
> {
> do something
> if (...) {
> pthread_unlock(obj);
> continue;
> }
> if (...) {
> pthread_unlock(obj);
> break;
> }
> if (....) {
> pthread_unlock(obj);
> return;
> }
> do something else
> } catch (...) {
> pthread_unlock(obj);
> throw;
> }
> pthread_unlock(obj);
>
>Personally I find the first way more readable and easier to maintain.

I'd argue that the critical region may be too large if all those
checks are required within.

I've used both, but in code (bare metal os/hv) compiled with
-fno-exceptions the following is preferable to RAII.

pthread_lock(obj);

if (xxx) goto unlock;

do something

if (yyy) goto unlock;

do something else

unlock:
pthread_unlock(obj);

six of one, half dozen of the other. This solution doesn't have
magic behavior and can more easily be reasoned to be correct.

Am 25.11.2023 um 18:28 schrieb Scott Lurndal:

> I've used both, but in code (bare metal os/hv) compiled with
> -fno-exceptions the following is preferable to RAII.
>
> pthread_lock(obj);
>
> if (xxx) goto unlock;
>
> do something
>
> if (yyy) goto unlock;
>
> do something else
>
> unlock:
> pthread_unlock(obj);

Why do you disable exceptions with code that doesn't throw ?

Bonita Montero <Bonita.Montero@gmail.com> writes:
>Am 25.11.2023 um 18:28 schrieb Scott Lurndal:
>
>> I've used both, but in code (bare metal os/hv) compiled with
>> -fno-exceptions the following is preferable to RAII.
>>
>> pthread_lock(obj);
>>
>> if (xxx) goto unlock;
>>
>> do something
>>
>> if (yyy) goto unlock;
>>
>> do something else
>>
>> unlock:
>> pthread_unlock(obj);
>
>Why do you disable exceptions with code that doesn't throw ?

To prevent the code from ever throwing, of course and to ensure
that no exception infrastructure gets generated into the object
files.

On 2023-11-25, Bonita Montero <Bonita.Montero@gmail.com> wrote:
> Am 24.11.2023 um 19:33 schrieb Kaz Kylheku:
>
>> It's just a syntactic sugar to avoid forgetting to unlock ...
>
> RAII is magnitudes more convenient and lass error-prone
> than manual resource handling.

Sure, but that's not necessarily an effective way to "sell" it to
someone who is being skeptical.

--
TXR Programming Language: http://nongnu.org/txr
Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal
Mastodon: @Kazinator@mstdn.ca
NOTE: If you use Google Groups, I don't see you, unless you're whitelisted.