Sorry, the code worked, but I don't need an atomic:

#include <iostream>
#include <thread>
#include <mutex>
#include <condition_variable>
#include <vector>

using namespace std;

int main( int argc, char **argv )
{ unsigned nProducers = jthread::hardware_concurrency() - 1;
if( (int)nProducers <= 0 )
return EXIT_FAILURE;
mutex mtx;
condition_variable cv;
constexpr uint64_t N_ITEMS = 10'000'000;
uint64_t itemOutput = 0;
auto producer = [&, inside = argc <= 1]()
{
static atomic_uint64_t itemCounter( 0 );
while( itemCounter.fetch_add( 1, memory_order_relaxed ) < N_ITEMS )
{
unique_lock lock( mtx );
++itemOutput;
if( inside )
cv.notify_one();
lock.unlock();
if( !inside )
cv.notify_one();
}
};
vector<jthread> procuders;
procuders.reserve( nProducers );
for( unsigned t = 0; t != nProducers; ++t )
procuders.emplace_back( producer );
uint64_t nextItem = 0;
for( ; ; )
{
unique_lock lock( mtx );
uint64_t lastItem;
while( (lastItem = itemOutput) < nextItem )
cv.wait( lock );
if( lastItem >= N_ITEMS )
break;
nextItem = lastItem;
}
}

It's early in the morning ...

Bonita Montero <Bonita.Montero@gmail.com> writes:
>Am 12.11.2023 um 18:53 schrieb Scott Lurndal:
>
>> No, you don't. If you updated the predicate that the condition
>> variable is monitoring while holding the mutex, you should release
>> the mutex before signaling or broadcasting the condition variable
>> to avoid unnecessary context switches.
>
>The context switch occurs only if _both_ conditions are met:
>the mutex is unlocked and the condition variable is signalled.

Ah, your not an expert on operating systems, it seems.

How would the OS know anything about the state of the mutex
associated with the condition variable?

Am 13.11.2023 um 16:05 schrieb Scott Lurndal:

> Ah, your not an expert on operating systems, it seems.

I've shown that my monitor has a slightly better performance than the
Linux mutex + condvar. So if they perform similar they dont have two
context switches for being signalled _and_ beging locked. Otherwise
the performance would be poorer.
And this code is not part of the kernel, but it used the kernel.

I've added some getrusage()s to take the number of voluntary context
switches. It's almost about the same for my monitor or a mutex and a
condvar under Linux. So the mutex plus condvar waits to be signalled
and released in one step, just as my monitor.

#include <iostream>
#include <thread>
#include <chrono>
#include <vector>
#include <mutex>
#include <condition_variable>
#include "monitor.h"
#if defined(__unix__)
#include <sys/resource.h>
#endif

using namespace std;
using namespace chrono;

int main( int argc, char **argv )
{ atomic_int64_t tSum;
#if defined(__unix__)
uint64_t lastVoluntary = 0;
auto voluntary = [&]()
{
rusage ru;
getrusage( RUSAGE_SELF, &ru );
uint64_t diff = ru.ru_nvcsw - lastVoluntary;
lastVoluntary = ru.ru_nvcsw;
return diff;
};
voluntary();
#endif
auto time = [&]( auto fn )
{
tSum = 0;
auto start = high_resolution_clock::now();
fn();
tSum += (int64_t)duration_cast<nanoseconds>(
high_resolution_clock::now() - start ).count();
};
constexpr size_t ROUNDS = 100'000;
struct not_t
{
monitor mon;
bool notifiy;
} notA { {}, true }, notB { {}, false };
notA.notifiy = true;
auto monThr = [&]( not_t &me, not_t &you )
{
time( [&]()
{
for( size_t r = ROUNDS; r; --r )
{
me.mon.lock();
for( ; !me.notifiy; me.mon.wait() );
me.notifiy = false;
me.mon.unlock();
you.mon.lock();
you.notifiy = true;
you.mon.notify();
you.mon.unlock();
}
} );
};
vector<jthread> threads;
threads.reserve( 0 );
threads.emplace_back( monThr, ref( notA ), ref( notB ) ),
threads.emplace_back( monThr, ref( notB ), ref( notA ) );
threads.resize( 0 );
cout << (double)tSum / (2.0 * ROUNDS) << endl;
#if defined(__unix__)
cout << "v: " << voluntary() << endl;
#endif
struct cv_t
{
mutex mtx;
condition_variable cv;
bool signal;
} cvA = { {}, {}, true }, cvB = { {}, {}, false };
auto cvThr = [&]( cv_t &cvMe, cv_t &cvYou )
{
time( [&]()
{
for( size_t r = ROUNDS; r; --r )
{
unique_lock<mutex> lockMe( cvMe.mtx );
for( ; !cvMe.signal; cvMe.cv.wait( lockMe ) );
cvMe.signal = false;
lockMe.unlock();
unique_lock<mutex> lockYou( cvYou.mtx );
cvYou.signal = true;
cvYou.cv.notify_one();
}
} );
};
threads.emplace_back( cvThr, ref( cvA ), ref( cvB ) );
threads.emplace_back( cvThr, ref( cvB ), ref( cvA ) );
threads.resize( 0 );
cout << (double)tSum / (2.0 * ROUNDS) << endl;
#if defined(__unix__)
cout << "v: " << voluntary() << endl;
#endif
}

On 11/12/2023 10:47 PM, Bonita Montero wrote:
> Sorry, the code worked, but I don't need an atomic:
[...]
> It's early in the morning ...

Yawn. Why not make sure it works _first_!?

On 11/12/2023 8:48 PM, Kaz Kylheku wrote:
> On 2023-11-13, Pavel <pauldontspamtolk@removeyourself.dontspam.yahoo> wrote:
>> Kaz Kylheku wrote:
>>> If you're using POSIX mutexes and conditions, you should call
>>> pthread_cond_signal and pthread_cond_broadcast outside of the mutex,
>>> whenever possible.
>> This is recommended against by the standard for the same reason why Java
>> implements Hoare monitor behavior. Citation:
>>
>> "
>> The pthread_cond_broadcast() or pthread_cond_signal() functions may be
>> called by a thread whether or not it currently owns the mutex that
>> threads calling pthread_cond_wait() or pthread_cond_timedwait() have
>> associated with the condition variable during their waits; however, if
>> predictable scheduling behavior is required, then that mutex shall be
>> locked by the thread calling pthread_cond_broadcast() or
>> pthread_cond_signal().
>> "
>
> But that text is stupid/defective, because you will not actually get
> predictable scheduling behavior just by doing that.
>
> Signal the condition while still holding the mutex doesn't give you any
> guarantees about which thread will get the mutex next.
>
> Suppose:
>
> 1. The signal operation wake up the next waiting thread.
>
> 2. The signaler then gives up the mutex.
>
> 3. Before that awoken next-waiting-thread gets the mutex, some
> another thread comes along and seizes the mutex.
>
> Signaling in the mutex can blow up the critical region from "handful of
> instructions" to "hundreds of instructions".
>
> If we compare:
>
> mutex_lock(&stack->lock);
> node->next = stack->top;
> stack->top = node;
> mutex_unlock(&stack->lock);
>
> cond_signal(&stack->item_pushed);
>
> All that is in the critical region are the mutex are the list
> manipulation instructions, plus some of the mutex code itself.
>
> If we move cond_signal before mutex_unlock, everything done by that
> function, including potentially going into the kernel to wake up a
> thread, is now in the mutex.

Excellent point. DING!

>
> That's a lot to pay for some vague, unfulfillable promise of
> "predictable scheduling behavior", on which you can base approximately
> nothing.
>
> Hoare semantics gives you something: that if there are waiting tasks
> queued on a condition, the monitor is transferred to the first waiting
> one. *And* (I seem to recall) when that thread leaves the monitor, the
> original signaler gets it again!
>

Kaz Kylheku wrote:
> On 2023-11-13, Pavel <pauldontspamtolk@removeyourself.dontspam.yahoo> wrote:
>> Kaz Kylheku wrote:
>>> If you're using POSIX mutexes and conditions, you should call
>>> pthread_cond_signal and pthread_cond_broadcast outside of the mutex,
>>> whenever possible.
>> This is recommended against by the standard for the same reason why Java
>> implements Hoare monitor behavior. Citation:
>>
>> "
>> The pthread_cond_broadcast() or pthread_cond_signal() functions may be
>> called by a thread whether or not it currently owns the mutex that
>> threads calling pthread_cond_wait() or pthread_cond_timedwait() have
>> associated with the condition variable during their waits; however, if
>> predictable scheduling behavior is required, then that mutex shall be
>> locked by the thread calling pthread_cond_broadcast() or
>> pthread_cond_signal().
>> "
>
> But that text is stupid/defective, because you will not actually get
> predictable scheduling behavior just by doing that.

This is POSIX text that IIRC was a compromise with real-time (RT) guys.
Java has thread priorities so it is formally relevant (could be relevant
in some implementations, too; did not really check). RT guys don't like
condvars in principle as they are a "gateway drug" to all kinds of prio
inversions so this was a compromise that permitted the condvar to get to
POSIX. The meaning of the spec is to prevent priority inversion when
running on one CPU. An example problematic scenario is as follows:

1. Higher-prio thread A grabs mutex and starts waiting for an event
(say, posted to a queue that's currently empty). The mutex is released
at this time to allow posting the event (the standard behavior of
pthread_cond_wait()).
2. Now that the A is not runnable, a lower-prio thread B can also run
and suppose it also wants event from same queue.
3. Thread C grabs mutex, posts event to the queue, releases the mutex
4. Before thread C manages to signal the condvar (and by that wake up
thread A), thread B grabs the lock and steals the event. Higher-prio
thread A stays waiting for the event -- which is what RT guys hate.

With the behavior recommended by the standard, thread C will first
notify condvar, by that making thread A runnable and thread A will grab
the event.

Kaz Kylheku wrote:
> On 2023-11-13, Pavel <pauldontspamtolk@removeyourself.dontspam.yahoo> wrote:
>> Kaz Kylheku wrote:
>>> If you're using POSIX mutexes and conditions, you should call
>>> pthread_cond_signal and pthread_cond_broadcast outside of the mutex,
>>> whenever possible.
>> This is recommended against by the standard for the same reason why Java
>> implements Hoare monitor behavior. Citation:
>>
>> "
>> The pthread_cond_broadcast() or pthread_cond_signal() functions may be
>> called by a thread whether or not it currently owns the mutex that
>> threads calling pthread_cond_wait() or pthread_cond_timedwait() have
>> associated with the condition variable during their waits; however, if
>> predictable scheduling behavior is required, then that mutex shall be
>> locked by the thread calling pthread_cond_broadcast() or
>> pthread_cond_signal().
>> "
>
> But that text is stupid/defective, because you will not actually get
> predictable scheduling behavior just by doing that.
>
> Signal the condition while still holding the mutex doesn't give you any
> guarantees about which thread will get the mutex next.
>
> Suppose:
>
> 1. The signal operation wake up the next waiting thread.
>
> 2. The signaler then gives up the mutex.
>
> 3. Before that awoken next-waiting-thread gets the mutex, some
> another thread comes along and seizes the mutex.
This is a gray area, the specs says:

When each thread unblocked as a result of a pthread_cond_broadcast() or
pthread_cond_signal() returns from its call to
pthread_cond_wait() or pthread_cond_timedwait(), the thread shall own
the mutex with which it called pthread_cond_wait() or
pthread_cond_timedwait(). The thread(s) that are un‐
blocked shall contend for the mutex according to the scheduling
policy (if applicable), and as if each had called pthread_mutex_lock().

"as-if" and "according to the scheduling policy (if applicable)" here
are important. The standard intent may be to permit only the threads
that are "unblocked" contend for the mutex -- as opposed to all
non-blocked threads. In other words, it is feasible reading of the
standard that, if the pthread_cond_signal caller owns the mutex, as
recommended, the scheduler may, within the signal call, get the threads
being unblocked "to the beginning of the line (queue) of the contenders
for the mutex" before the signalling thread has a chance to do anything
(in particular, release the mutex). Then another thread has no chance of
seizing the mutex.

>
> Signaling in the mutex can blow up the critical region from "handful of
> instructions" to "hundreds of instructions".
RT is all about discipline to achieve low latency of serving some
requests. It is not about high throughput.

In fact, implementing ANY scheduling policy, even simple FIFO (although
even defining a FIFO policy on a multi-CPU system is not as simple),
incurs costs as compared to "no policy". RT policies are even more
expensive. For some systems they make sense, for some they don't. POSIX
threads extension was worked on largely in parallel with RT extension
and this shows in the product.

>
> If we compare:
>
> mutex_lock(&stack->lock);
> node->next = stack->top;
> stack->top = node;
> mutex_unlock(&stack->lock);
>
> cond_signal(&stack->item_pushed);
>
> All that is in the critical region are the mutex are the list
> manipulation instructions, plus some of the mutex code itself.
>
> If we move cond_signal before mutex_unlock, everything done by that
> function, including potentially going into the kernel to wake up a
> thread, is now in the mutex.
>
> That's a lot to pay for some vague, unfulfillable promise of
> "predictable scheduling behavior", on which you can base approximately
> nothing.
>
> Hoare semantics gives you something: that if there are waiting tasks
> queued on a condition, the monitor is transferred to the first waiting
> one. *And* (I seem to recall) when that thread leaves the monitor, the
> original signaler gets it again!
>

Kaz Kylheku wrote:
> On 2023-11-13, Pavel <pauldontspamtolk@removeyourself.dontspam.yahoo> wrote:
>> Scott Lurndal wrote:
>>> No, you don't. If you updated the predicate that the condition
>>> variable is monitoring while holding the mutex, you should release
>>> the mutex before signaling or broadcasting the condition variable
>>> to avoid unnecessary context switches.
>>>
>> Why would you have additional context switches if you signal before
>> releasing the lock?
>
> Because of the situation that the thread which was signaled is
> trying to acquire the mutex, which, stupidly, the signaling thread
> is still holding. So, oops, back it goes into suspended state, and we
> have to context switch to the mutex holder which has to release the
> mutex and then switch to that signaled thread again.
>
Please see my response to your other post. "as-if" calling of
pthread_mutex_lock does not prescribe actually calling it. Nothing in
the standard prevents pthread_cond_signal from doing all the job of
stuffing the unblocked threads to the mutex waiting list in accordance
with some scheduling policy. They don't really need to leave the
non-runnable state until the mutex is released.

On 2023-11-14, Pavel <pauldontspamtolk@removeyourself.dontspam.yahoo> wrote:
> "as-if" and "according to the scheduling policy (if applicable)" here
> are important. The standard intent may be to permit only the threads
> that are "unblocked" contend for the mutex -- as opposed to all
> non-blocked threads.

It's possible that only one thread is unblocked by a
pthread_cond_signal. It takes at least two parties to contend for
something.

--
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 2023-11-14, Pavel <pauldontspamtolk@removeyourself.dontspam.yahoo> wrote:
> Kaz Kylheku wrote:
>> Because of the situation that the thread which was signaled is
>> trying to acquire the mutex, which, stupidly, the signaling thread
>> is still holding. So, oops, back it goes into suspended state, and we
>> have to context switch to the mutex holder which has to release the
>> mutex and then switch to that signaled thread again.
>>
> Please see my response to your other post. "as-if" calling of
> pthread_mutex_lock does not prescribe actually calling it. Nothing in
> the standard prevents pthread_cond_signal from doing all the job of
> stuffing the unblocked threads to the mutex waiting list in accordance
> with some scheduling policy.

Have you noticed how no mutex appears in the pthread_cond_signal API?

--
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.

Am 13.11.2023 um 21:50 schrieb Chris M. Thomasson:
> On 11/12/2023 10:47 PM, Bonita Montero wrote:
>> Sorry, the code worked, but I don't need an atomic:
> [...]
>> It's early in the morning ...
>
> Yawn. Why not make sure it works _first_!?

The first code worked but the atomic could be a normal uint64_t
since its access is surrounded by a mutex lock and unlock.

On 11/13/2023 9:20 PM, Bonita Montero wrote:
> Am 13.11.2023 um 21:50 schrieb Chris M. Thomasson:
>> On 11/12/2023 10:47 PM, Bonita Montero wrote:
>>> Sorry, the code worked, but I don't need an atomic:
>> [...]
>>> It's early in the morning ...
>>
>> Yawn. Why not make sure it works _first_!?
>
> The first code worked but the atomic could be a normal uint64_t
> since its access is surrounded by a mutex lock and unlock.
>

You mean a word wrt the arch, or uint64_t on a 32-bit system?

On 11/13/2023 7:27 PM, Kaz Kylheku wrote:
> On 2023-11-14, Pavel <pauldontspamtolk@removeyourself.dontspam.yahoo> wrote:
>> "as-if" and "according to the scheduling policy (if applicable)" here
>> are important. The standard intent may be to permit only the threads
>> that are "unblocked" contend for the mutex -- as opposed to all
>> non-blocked threads.
>
> It's possible that only one thread is unblocked by a
> pthread_cond_signal. It takes at least two parties to contend for
> something.
>

A signalling thread does its thing while holding the mutex... Well, it
hears the following playing in the background:

https://youtu.be/7YvAYIJSSZY

On 11/13/2023 9:28 PM, Chris M. Thomasson wrote:
> On 11/13/2023 7:27 PM, Kaz Kylheku wrote:
>> On 2023-11-14, Pavel <pauldontspamtolk@removeyourself.dontspam.yahoo>
>> wrote:
>>> "as-if" and "according to the scheduling policy (if applicable)" here
>>> are important. The standard intent may be to permit only the threads
>>> that are "unblocked" contend for the mutex -- as opposed to all
>>> non-blocked threads.
>>
>> It's possible that only one thread is unblocked by a
>> pthread_cond_signal. It takes at least two parties to contend for
>> something.
>>
>
> A signalling thread does its thing while holding the mutex... Well, it
> hears the following playing in the background:
>
> https://youtu.be/7YvAYIJSSZY

A condvar that cannot signal/broadcast from outside of a held mutex is
broken by default.

On 11/13/2023 7:30 PM, Kaz Kylheku wrote:
> On 2023-11-14, Pavel <pauldontspamtolk@removeyourself.dontspam.yahoo> wrote:
>> Kaz Kylheku wrote:
>>> Because of the situation that the thread which was signaled is
>>> trying to acquire the mutex, which, stupidly, the signaling thread
>>> is still holding. So, oops, back it goes into suspended state, and we
>>> have to context switch to the mutex holder which has to release the
>>> mutex and then switch to that signaled thread again.
>>>
>> Please see my response to your other post. "as-if" calling of
>> pthread_mutex_lock does not prescribe actually calling it. Nothing in
>> the standard prevents pthread_cond_signal from doing all the job of
>> stuffing the unblocked threads to the mutex waiting list in accordance
>> with some scheduling policy.
>
> Have you noticed how no mutex appears in the pthread_cond_signal API?
>

DING!

Am 14.11.2023 um 06:21 schrieb Chris M. Thomasson:

> You mean a word wrt the arch, or uint64_t on a 32-bit system?

itemOutput first was a atomic_uint64_t and now is a uint64_t.
The atomicwasn't necessary because itemOutput is accessed within
a mutex access, i.e. it is surrounded with a lock() and unlock()
which itself have a acquire and release behaviour, so I itemOutput
doesn't need to be atomic.

On 11/11/2023 11:41 AM, Chris M. Thomasson wrote:
> On 11/11/2023 2:41 AM, Bonita Montero wrote:
>> I think I've put the finishing touches to the code now. For the mutex
>> part I introduced spinning, which I adopted from glibc. Spinning usually
> [...]
>
> Food for thought... I learned something really neat over on comp.arch
> wrt Lynn Wheeler many years ago. Basically, why spin doing nothing? Oh,
> you use a yield... Well, that is still doing nothing. Think of a spin
> along the lines of:
>
> we try to use accomplished work as a backoff/yield for a spin...
>
>
> <quick pseudo-code>
> ______________
> void lock()
> {
>   while (! mutex_trylock())
>   {
>     // try to do some "other" work as a
>     // yield, in a sense... Hummm.... ;^)
>     if (! try_to_do_some__other__work())
>     {
>         // failed to do some other work, lock it...
>     mutex_lock();
>         break;
>     }
>   }
>
>   // we are locked! =^D
> }
>
> void unlock()
> {
>   mutex_unlock();
> }
> ______________
>
>
> Well, this can be beneficial in certain setups...

Train Control... Can other work be done instead of spinning on a
spinlock? Humm...

https://youtu.be/Gm0NWMdcbmU

On 11/13/2023 10:44 PM, Bonita Montero wrote:
> Am 14.11.2023 um 06:21 schrieb Chris M. Thomasson:
>
>> You mean a word wrt the arch, or uint64_t on a 32-bit system?
>
> itemOutput first was a atomic_uint64_t and now is a uint64_t.
> The atomicwasn't necessary because itemOutput is accessed within
> a mutex access, i.e. it is surrounded with a lock() and unlock()
> which itself have a acquire and release behaviour, so I itemOutput
> doesn't need to be atomic.
>

If you say so. I have not had enough time to study up on your code. Btw,
are you finished with any bug fixes? Are you sure it might not have any
spinning out of control aspects to it? If I do model it, we need to get
to a concrete version of it, you say this is it, I say okay, call it
BonitaMonitorVersion1. Fair enough?

https://youtu.be/T_U3Zdv8to8

On 11/13/2023 10:51 PM, Chris M. Thomasson wrote:
> On 11/13/2023 10:44 PM, Bonita Montero wrote:
>> Am 14.11.2023 um 06:21 schrieb Chris M. Thomasson:
>>
>>> You mean a word wrt the arch, or uint64_t on a 32-bit system?
>>
>> itemOutput first was a atomic_uint64_t and now is a uint64_t.
>> The atomicwasn't necessary because itemOutput is accessed within
>> a mutex access, i.e. it is surrounded with a lock() and unlock()
>> which itself have a acquire and release behaviour, so I itemOutput
>> doesn't need to be atomic.
>>
>
> If you say so. I have not had enough time to study up on your code. Btw,
> are you finished with any bug fixes? Are you sure it might not have any
> spinning out of control aspects to it? If I do model it, we need to get
> to a concrete version of it, you say this is it, I say okay, call it
> BonitaMonitorVersion1. Fair enough?
>
> https://youtu.be/T_U3Zdv8to8

Put your version that you know works up in github or something. Name it,
then I can get to work on it. I don't want to hear about any bug fixes
as I am porting it over to a Relacy test unit. Fair enough? Say THIS IS IT!

https://youtu.be/U8SSdyflGN4

Done. Then, we can get to work.

Am 14.11.2023 um 07:51 schrieb Chris M. Thomasson:

> If you say so. I have not had enough time to study up on your code. Btw,
> are you finished with any bug fixes? Are you sure it might not have any
> spinning out of control aspects to it? If I do model it, we need to get
> to a concrete version of it, you say this is it, I say okay, call it
> BonitaMonitorVersion1. Fair enough?

I've got a class thead_queue which I used for years. I changed it to
use my monitor instead a mutex plus condition variable. And the thead
_queue is used a lot and the code that used it works as before. That's
so much randomized synchronization for that that I for sure don't need
any Ralacy or whatever.

Am 14.11.2023 um 08:00 schrieb Bonita Montero:
> Am 14.11.2023 um 07:51 schrieb Chris M. Thomasson:
>
>> If you say so. I have not had enough time to study up on your code.
>> Btw, are you finished with any bug fixes? Are you sure it might not
>> have any spinning out of control aspects to it? If I do model it, we
>> need to get to a concrete version of it, you say this is it, I say
>> okay, call it BonitaMonitorVersion1. Fair enough?
>
> I've got a class thead_queue ...

This is my thread_queue in the version where I didn't use my monitor:

#pragma once
#include <deque>
#include <mutex>
#include <condition_variable>
#include <utility>
#include <concepts>
#include <list>
#include <deque>
#include "invoke_on_destruct.h"

template<typename Entity, typename Allocator = std::allocator<Entity>>
struct thread_queue
{ thread_queue();
explicit thread_queue( Allocator const &alloc );
thread_queue( thread_queue const & ) = delete;
thread_queue( thread_queue &&other );
thread_queue &operator =( thread_queue const & ) = delete;
thread_queue &operator =( thread_queue &&other );
bool empty() const;
size_t size() const;
void shrink_to_fit();
void clear();
template<typename ... Args>
requires std::is_constructible_v<Entity, Args ...>
void enque( Args &&... args );
template<typename Producer>
requires requires( Producer producer ) { { producer() } ->
std::same_as<std::pair<bool, Entity>>; }
void enqueue_multiple( Producer producer );
template<typename Consumer>
requires requires( Consumer consumer, Entity value ) { { consumer(
std::move( value ) ) } -> std::same_as<bool>; }
|| requires( Consumer consumer, size_t remaining, Entity value ) { {
consumer( remaining, std::move( value ) ) } -> std::same_as<bool>; }
void dequeue_multiple( Consumer consumer );
Entity dequeue();
std::deque<Entity, Allocator> deque();
private:
mutable std::mutex m_mtx;
mutable std::condition_variable m_cv;
std::deque<Entity, Allocator> m_queue;
};

template<typename Entity, typename Allocator>
thread_queue<Entity, Allocator>::thread_queue()
{ }

template<typename Entity, typename Allocator>
thread_queue<Entity, Allocator>::thread_queue( Allocator const &alloc ) :
m_queue( alloc )
{ }

template<typename Entity, typename Allocator>
thread_queue<Entity, Allocator>::thread_queue( thread_queue &&other )
{ std::scoped_lock lock( m_mtx );
m_queue = move( other.m_queue );
}

template<typename Entity, typename Allocator>
thread_queue<Entity, Allocator> &thread_queue<Entity,
Allocator>::thread_queue::operator =( thread_queue &&other )
{ using namespace std;
lock_guard
ourlock( m_mtx ),
otherLock( other.m_mon );
m_queue = move( other.m_queue );
return *this;
}

template<typename Entity, typename Allocator>
bool thread_queue<Entity, Allocator>::thread_queue::empty() const
{ std::lock_guard lock( m_mtx );
return m_queue.empty();
}

template<typename Entity, typename Allocator>
size_t thread_queue<Entity, Allocator>::thread_queue::size() const
{ std::lock_guard lock( m_mtx );
return m_queue.size();
}

template<typename Entity, typename Allocator>
void thread_queue<Entity, Allocator>::thread_queue::shrink_to_fit()
{ std::lock_guard lock( m_mtx );
return m_queue.shrink_to_fit();
}

template<typename Entity, typename Allocator>
void thread_queue<Entity, Allocator>::thread_queue::clear()
{ std::lock_guard lock( m_mtx );
m_queue.clear();
}

template<typename Entity, typename Allocator>
template<typename ... Args>
requires std::is_constructible_v<Entity, Args ...>
void thread_queue<Entity, Allocator>::thread_queue::enque( Args &&... args )
{ using namespace std;
unique_lock lock( m_mtx );
m_queue.emplace_front( forward<Args>( args ) ... );
m_cv.notify_one();
}

template<typename Entity, typename Allocator>
Entity thread_queue<Entity, Allocator>::thread_queue::dequeue()
{ using namespace std;
unique_lock lock( m_mtx );
while( m_queue.empty() )
m_cv.wait( lock );
Entity value = move( m_queue.back() );
m_queue.pop_back();
return value;
}

template<typename Entity, typename Allocator>
template<typename Producer>
requires requires( Producer producer ) { { producer() } ->
std::same_as<std::pair<bool, Entity>>; }
void thread_queue<Entity, Allocator>::enqueue_multiple( Producer producer )
{ using namespace std;
lock_guard lock( m_mtx );
for( pair<bool, Entity> ret; (ret = move( producer() )).first; )
m_queue.emplace_front( move( ret.second ) ),
m_cv.notify_one();
}

template<typename Entity, typename Allocator>
template<typename Consumer>
requires requires( Consumer consumer, Entity value ) { { consumer(
std::move( value ) ) } -> std::same_as<bool>; }
|| requires( Consumer consumer, size_t remaining, Entity value ) { {
consumer( remaining, std::move( value ) ) } -> std::same_as<bool>; }
void thread_queue<Entity, Allocator>::dequeue_multiple( Consumer consumer )
{ using namespace std;
unique_lock lock( m_mtx );
for( ; ; )
{
while( m_queue.empty() )
m_cv.wait( lock );
invoke_on_destruct popBack( [&]() { m_queue.pop_back(); } );
if constexpr( requires( Consumer consumer, Entity value ) { {
consumer( std::move( value ) ) } -> std::same_as<bool>; } )
if( !consumer( move( m_queue.back() ) ) )
return;
else;
else
if( !consumer( m_queue.size(), move( m_queue.back() ) ) )
return;
}
}

template<typename Entity, typename Allocator>
std::deque<Entity, Allocator> thread_queue<Entity, Allocator>::deque()
{ using namespace std;
unique_lock lock( m_mtx );
return move( m_queue );
}

Concepts rock !

On 11/13/2023 11:00 PM, Bonita Montero wrote:
> Am 14.11.2023 um 07:51 schrieb Chris M. Thomasson:
>
>> If you say so. I have not had enough time to study up on your code.
>> Btw, are you finished with any bug fixes? Are you sure it might not
>> have any spinning out of control aspects to it? If I do model it, we
>> need to get to a concrete version of it, you say this is it, I say
>> okay, call it BonitaMonitorVersion1. Fair enough?
>
> I've got a class thead_queue which I used for years. I changed it to
> use my monitor instead a mutex plus condition variable. And the thead
> _queue is used a lot and the code that used it works as before. That's
> so much randomized synchronization for that that I for sure don't need
> any Ralacy or whatever.
>

Just get a concrete version of your Monitor, say done. Think... Think
again... No bug fixes allowed, unless Relacy finds one. Could be a very
subtle memory order issue that you might of missed...

On 11/13/2023 11:07 PM, Bonita Montero wrote:
> Am 14.11.2023 um 08:00 schrieb Bonita Montero:
>> Am 14.11.2023 um 07:51 schrieb Chris M. Thomasson:
>>
>>> If you say so. I have not had enough time to study up on your code.
>>> Btw, are you finished with any bug fixes? Are you sure it might not
>>> have any spinning out of control aspects to it? If I do model it, we
>>> need to get to a concrete version of it, you say this is it, I say
>>> okay, call it BonitaMonitorVersion1. Fair enough?
>>
>> I've got a class thead_queue ...
>
> This is my thread_queue in the version where I didn't use my monitor:
[...]
> Concepts rock !

I had your monitor on the mind...

On 11/12/2023 12:46 PM, Chris M. Thomasson wrote:
> On 11/11/2023 8:40 PM, Bonita Montero wrote:
>> Am 11.11.2023 um 20:42 schrieb Chris M. Thomasson:
>>
>>> Is that yet another bug correction? Remember my advise, get it
>>> working then try to make it faster.
>>
>> The code immediately crashed because of an exception;
>> easiest debugging.
>>
>
> Yet, you missed it? Actually, I am not quite sure how to parse your
> response. I have not had the free time to port your code over to a
> Relacy test unit, yet...
>
> :^)

Get it to a point where you can say, no more corrections are needed, for
SURE! Then shine it one me you crazy diamond:

https://youtu.be/54W8kktFE_o?t=524

;^)