Once I've written a thread pool that has an upper limit of the number
threads and a timeout when idle threads end theirselfes. If you have
sth userpace CPU bound you'd specify the number of hardware-threads
as the upper limit, if you have much threads doing I/O you may go far
beyond since the hardware-threads aren't fully occupied anyway.
The problem with my initial thread pool class was that there may be
a large number of idle threads which could be used by other pools.
So I wrote a thread pool class where each pool has an upper limit of
the number of executing threads and there are no idle threads within
each pool. Instead the threads go idling in a global singleton pool
and attach to each pool which needs a new thread, thereby minimizing
the total number of threads.

This is the implementation

// header

#pragma once
#include <thread>
#include <mutex>
#include <condition_variable>
#include <deque>
#include <functional>
#include <chrono>

struct thread_pool
{ using void_fn = std::function<void ()>;
thread_pool( size_t maxThreads = 0 );
thread_pool( thread_pool const & ) = delete;
void operator =( thread_pool const & ) = delete;
~thread_pool();
uint64_t enqueue_task( void_fn &&task );
void_fn cancel( uint64_t queueId );
void wait_idle();
size_t max_threads();
size_t resize( size_t maxThreads );
bool clear_queue();
void_fn idle_callback( void_fn &&fn = {} );
std::pair<size_t, size_t> processing();
static typename std::chrono::milliseconds timeout(
std::chrono::milliseconds timeout );
private:
struct idle_node
{
idle_node *next;
bool notify;
};
using queue_item = std::pair<uint64_t, void_fn>;
using task_queue_t = std::deque<queue_item>;
bool m_quit;
size_t
m_maxThreads,
m_nThreadsExecuting;
uint64_t
m_lastIdleQueueId,
m_nextQueueId;
task_queue_t m_queue;
std::condition_variable m_idleCv;
std::shared_ptr<void_fn> m_idleCallback;
idle_node *m_idleList;
inline static struct global_t
{
std::mutex m_mtx;
std::chrono::milliseconds m_timeout = std::chrono::seconds( 1 );
std::condition_variable
m_cv,
m_quitCv;
bool m_quit;
size_t
m_nThreads,
m_nThreadsActive;
std::deque<thread_pool *> m_initiate;
void theThread();
global_t();
~global_t();
} global;
void processIdle( std::unique_lock<std::mutex> &lock );
std::unique_lock<std::mutex> waitIdle();
};

// translation unit

#include <cassert>
#include "thread_pool.h"
#include "invoke_on_destruct.h"

#if defined(_WIN32)
#pragma warning(disable: 26110) // Caller failing to hold lock
'lock' before calling function 'func'.
#pragma warning(disable: 26111) // Caller failing to release lock
'lock' before calling function 'func'.
#pragma warning(disable: 26115) // Failing to release lock 'lock'
in function 'func'.
#pragma warning(disable: 26117) // Releasing unheld lock 'lock' in
function 'func'.
#pragma warning(disable: 26800) // Use of a moved from object:
'object'.
#endif
#if defined(__llvm__)
#pragma clang diagnostic ignored "-Wparentheses"
#pragma clang diagnostic ignored "-Wunqualified-std-cast-call"
#endif

using namespace std;
using namespace chrono;

thread_pool::thread_pool( size_t maxThreads ) :
m_quit( false ),
m_maxThreads( [&]()
{
if( size_t hc; !maxThreads )
hc = jthread::hardware_concurrency(),
maxThreads = hc ? hc : 1;
return maxThreads;
}() ),
m_nThreadsExecuting( 0 ),
m_lastIdleQueueId( 0 ),
m_nextQueueId( 0 ),
m_idleList( nullptr )
{ }

// may throw system_error

thread_pool::~thread_pool()
{ // wait for idling and inherit the lock
unique_lock lock( waitIdle() );
// erase all outstanding spurious initiations to our pool;
// spurious because of stolen wakeups, non-cancelled initiations or
queue-clears
erase( global.m_initiate, this );
}

void thread_pool::global_t::theThread()
{ try
{
unique_lock lock( m_mtx );
// the first thread never waits with a timeout
bool reserve = m_nThreads == 1;
// reseved timeout which determines the beginning of a wait period
constexpr auto BEGIN_WAIT = time_point<steady_clock>(
steady_clock::duration( -1 ) );
auto start = BEGIN_WAIT;
for( ; ; )
{
while( !m_initiate.size() )
{
// quitting ?
if( m_quit )
{
// the initiation-queue is empty, we can quit;
// we're the last thread ?
if( !--m_nThreads )
// yes: notify the quitting thread's destructor
m_quitCv.notify_one();
return;
}
// it's our first round waiting, i.e. we're not coming
from a spurious initiation ?
if( start.time_since_epoch().count() < 0 )
// yes: set wating start time
start = steady_clock::now();
// we don't have any timeout or we're the reserve-thread ?
if( m_timeout.count() <= 0 || reserve )
// yes: wait for condition without timeout
m_cv.wait( lock );
else
{
// wait for condition with timeout;
// timeout and there are surplus threads and we're
not quitting ?
auto availAssert = []( size_t a ) {
assert((ptrdiff_t)a >= 0); return a; };
if( m_cv.wait_until( lock, start + m_timeout ) !=
cv_status::no_timeout
&& availAssert( m_nThreads - m_nThreadsActive )
> m_initiate.size() && !m_quit )
// yes: release thread
return (void)--m_nThreads;
}
}
// pop first initiate-entry
thread_pool *pool = m_initiate.front();
m_initiate.pop_front();
// pool is empty (spurious or stolen wakeup) or there are
enough running
// threads because the maximum number of threads has been
changed meanwhile ?
if( !pool->m_queue.size() || pool->m_nThreadsExecuting >=
pool->m_maxThreads )
// continue to wait at last start, keeping timeout due time
continue;
// our thread is marked running globally
++m_nThreadsActive;
// our thread is running inside a pool
++pool->m_nThreadsExecuting;
do
{
// pop worker-function
void_fn fn( move( pool->m_queue.front().second ) );
pool->m_queue.pop_front();
// call worker-item unlocked
lock.unlock();
fn();
lock.lock();
// repeat while pool still has items and the maximum
number of threads isn't exhausted;
// both pool-values could have changed while we were
unlocked
} while( pool->m_queue.size() && pool->m_nThreadsExecuting
<= pool->m_maxThreads );
// our thread is removed from the pool
--pool->m_nThreadsExecuting;
// our thread is available again
--m_nThreadsActive;
// ilde-notify
pool->processIdle( lock );
if( !lock )
lock.lock();
// continue with new timeout
start = BEGIN_WAIT;
}
}
catch( ... )
{
terminate();
}
}

void thread_pool::processIdle( std::unique_lock<mutex> &lock )
{ assert(lock);
// we're idling ?
if( m_queue.size() || m_nThreadsExecuting )
// no idle processing
return;
// update idle queue-id
m_lastIdleQueueId = m_nextQueueId;
// there are waiting synchronous idlers in the idle-list ?
if( idle_node *idler = m_idleList; idler )
{
// notify all synchronous idlers
do
idler->notify = true;
while( idler = idler->next );
// doesn't throw
m_idleCv.notify_all();
// idle-list is empty now
m_idleList = nullptr;
}
// there's no asynchronous idle-callback ?
if( !m_idleCallback )
return;
// lock current idle-pointer
shared_ptr<void_fn> idleCallback( m_idleCallback );
lock.unlock();
// call asynchronous idler
try
{
(*idleCallback)();
}
catch( ... )
{
terminate();
}
}

On 1/25/2024 9:25 AM, Bonita Montero wrote:
>
> Once I've written a thread pool that has an upper limit of the number
> threads and a timeout when idle threads end theirselfes. If you have
> sth userpace CPU bound you'd specify the number of hardware-threads
> as the upper limit, if you have much threads doing I/O you may go far
> beyond since the hardware-threads aren't fully occupied anyway.
> The problem with my initial thread pool class was that there may be
> a large number of idle threads which could be used by other pools.
> So I wrote a thread pool class where each pool has an upper limit of
> the number of executing threads and there are no idle threads within
> each pool. Instead the threads go idling in a global singleton pool
> and attach to each pool which needs a new thread, thereby minimizing
> the total number of threads.
>
> This is the implementation
[...]

Just make sure to take the time to model it in a race detector.

Am 25.01.2024 um 20:31 schrieb Chris M. Thomasson:
> On 1/25/2024 9:25 AM, Bonita Montero wrote:
>>
>> Once I've written a thread pool that has an upper limit of the number
>> threads and a timeout when idle threads end theirselfes. If you have
>> sth userpace CPU bound you'd specify the number of hardware-threads
>> as the upper limit, if you have much threads doing I/O you may go far
>> beyond since the hardware-threads aren't fully occupied anyway.
>> The problem with my initial thread pool class was that there may be
>> a large number of idle threads which could be used by other pools.
>> So I wrote a thread pool class where each pool has an upper limit of
>> the number of executing threads and there are no idle threads within
>> each pool. Instead the threads go idling in a global singleton pool
>> and attach to each pool which needs a new thread, thereby minimizing
>> the total number of threads.
>>
>> This is the implementation
> [...]
>
> Just make sure to take the time to model it in a race detector.

Idiot ...

On 1/25/2024 8:08 PM, Bonita Montero wrote:
> Am 25.01.2024 um 20:31 schrieb Chris M. Thomasson:
>> On 1/25/2024 9:25 AM, Bonita Montero wrote:
>>>
>>> Once I've written a thread pool that has an upper limit of the number
>>> threads and a timeout when idle threads end theirselfes. If you have
>>> sth userpace CPU bound you'd specify the number of hardware-threads
>>> as the upper limit, if you have much threads doing I/O you may go far
>>> beyond since the hardware-threads aren't fully occupied anyway.
>>> The problem with my initial thread pool class was that there may be
>>> a large number of idle threads which could be used by other pools.
>>> So I wrote a thread pool class where each pool has an upper limit of
>>> the number of executing threads and there are no idle threads within
>>> each pool. Instead the threads go idling in a global singleton pool
>>> and attach to each pool which needs a new thread, thereby minimizing
>>> the total number of threads.
>>>
>>> This is the implementation
>> [...]
>>
>> Just make sure to take the time to model it in a race detector.
>
> Idiot ...

Sigh. I don't have the time to look over your code and find any
potential issues right now. I will wait for one of your infamous
corrections instead. At least if you said here are some test units and
they pass, well, that would be a good sign, right? :^)

On 1/25/2024 8:08 PM, Bonita Montero wrote:
> Am 25.01.2024 um 20:31 schrieb Chris M. Thomasson:
>> On 1/25/2024 9:25 AM, Bonita Montero wrote:
>>>
>>> Once I've written a thread pool that has an upper limit of the number
>>> threads and a timeout when idle threads end theirselfes. If you have
>>> sth userpace CPU bound you'd specify the number of hardware-threads
>>> as the upper limit, if you have much threads doing I/O you may go far
>>> beyond since the hardware-threads aren't fully occupied anyway.
>>> The problem with my initial thread pool class was that there may be
>>> a large number of idle threads which could be used by other pools.
>>> So I wrote a thread pool class where each pool has an upper limit of
>>> the number of executing threads and there are no idle threads within
>>> each pool. Instead the threads go idling in a global singleton pool
>>> and attach to each pool which needs a new thread, thereby minimizing
>>> the total number of threads.
>>>
>>> This is the implementation
>> [...]
>>
>> Just make sure to take the time to model it in a race detector.
>
> Idiot ...
>
>

Don't be ashamed of creating a test unit. If it find any errors, just
correct them, right? Notice how I formulated my xchg algortihm in a test
unit first!

https://groups.google.com/g/comp.lang.c++/c/Skv1PoQsUZo/m/bZoTXWDkAAAJ

No shame in that! Right? :^)

On 1/26/2024 7:23 PM, Chris M. Thomasson wrote:
> On 1/25/2024 8:08 PM, Bonita Montero wrote:
>> Am 25.01.2024 um 20:31 schrieb Chris M. Thomasson:
>>> On 1/25/2024 9:25 AM, Bonita Montero wrote:
>>>>
>>>> Once I've written a thread pool that has an upper limit of the number
>>>> threads and a timeout when idle threads end theirselfes. If you have
>>>> sth userpace CPU bound you'd specify the number of hardware-threads
>>>> as the upper limit, if you have much threads doing I/O you may go far
>>>> beyond since the hardware-threads aren't fully occupied anyway.
>>>> The problem with my initial thread pool class was that there may be
>>>> a large number of idle threads which could be used by other pools.
>>>> So I wrote a thread pool class where each pool has an upper limit of
>>>> the number of executing threads and there are no idle threads within
>>>> each pool. Instead the threads go idling in a global singleton pool
>>>> and attach to each pool which needs a new thread, thereby minimizing
>>>> the total number of threads.
>>>>
>>>> This is the implementation
>>> [...]
>>>
>>> Just make sure to take the time to model it in a race detector.
>>
>> Idiot ...
>>
>>
>
> Don't be ashamed of creating a test unit. If it find any errors, just
> correct them, right? Notice how I formulated my xchg algortihm in a test
> unit first!
>
> https://groups.google.com/g/comp.lang.c++/c/Skv1PoQsUZo/m/bZoTXWDkAAAJ
>
> No shame in that! Right? :^)

Give it a go? https://github.com/dvyukov/relacy

Am 25.01.2024 um 20:31 schrieb Chris M. Thomasson:
> On 1/25/2024 9:25 AM, Bonita Montero wrote:
>>
>> Once I've written a thread pool that has an upper limit of the number
>> threads and a timeout when idle threads end theirselfes. If you have
>> sth userpace CPU bound you'd specify the number of hardware-threads
>> as the upper limit, if you have much threads doing I/O you may go far
>> beyond since the hardware-threads aren't fully occupied anyway.
>> The problem with my initial thread pool class was that there may be
>> a large number of idle threads which could be used by other pools.
>> So I wrote a thread pool class where each pool has an upper limit of
>> the number of executing threads and there are no idle threads within
>> each pool. Instead the threads go idling in a global singleton pool
>> and attach to each pool which needs a new thread, thereby minimizing
>> the total number of threads.
>>
>> This is the implementation
> [...]
>
> Just make sure to take the time to model it in a race detector.
>

The synchronization part is trivial.
It's the state the synchronization manages that is complex.

On 1/25/2024 9:25 AM, Bonita Montero wrote:
>
> Once I've written a thread pool that has an upper limit of the number
> threads and a timeout when idle threads end theirselfes. If you have
> sth userpace CPU bound you'd specify the number of hardware-threads
> as the upper limit, if you have much threads doing I/O you may go far
> beyond since the hardware-threads aren't fully occupied anyway.
> The problem with my initial thread pool class was that there may be
> a large number of idle threads which could be used by other pools.
> So I wrote a thread pool class where each pool has an upper limit of
> the number of executing threads and there are no idle threads within
> each pool. Instead the threads go idling in a global singleton pool
> and attach to each pool which needs a new thread, thereby minimizing
> the total number of threads.
>
> This is the implementation
>
> // header
>
> #pragma once
> #include <thread>
> #include <mutex>
> #include <condition_variable>
> #include <deque>
> #include <functional>
> #include <chrono>
>
> struct thread_pool

[...]

>
> // translation unit
>
> #include <cassert>
> #include "thread_pool.h"
> #include "invoke_on_destruct.h"
>
> #if defined(_WIN32)
>     #pragma warning(disable: 26110) // Caller failing to hold lock
> 'lock' before calling function 'func'.
>     #pragma warning(disable: 26111) // Caller failing to release lock
> 'lock' before calling function 'func'.
>     #pragma warning(disable: 26115) // Failing to release lock 'lock'
> in function 'func'.
>     #pragma warning(disable: 26117) // Releasing unheld lock 'lock' in
> function 'func'.
>     #pragma warning(disable: 26800) // Use of a moved from object:
> 'object'.
> #endif
> #if defined(__llvm__)
>     #pragma clang diagnostic ignored "-Wparentheses"
>     #pragma clang diagnostic ignored "-Wunqualified-std-cast-call"
> #endif
[...]

Pardon my french, but what the heck is all of this for, exactly...

?

On 1/27/2024 12:38 AM, Bonita Montero wrote:
> Am 25.01.2024 um 20:31 schrieb Chris M. Thomasson:
>> On 1/25/2024 9:25 AM, Bonita Montero wrote:
>>>
>>> Once I've written a thread pool that has an upper limit of the number
>>> threads and a timeout when idle threads end theirselfes. If you have
>>> sth userpace CPU bound you'd specify the number of hardware-threads
>>> as the upper limit, if you have much threads doing I/O you may go far
>>> beyond since the hardware-threads aren't fully occupied anyway.
>>> The problem with my initial thread pool class was that there may be
>>> a large number of idle threads which could be used by other pools.
>>> So I wrote a thread pool class where each pool has an upper limit of
>>> the number of executing threads and there are no idle threads within
>>> each pool. Instead the threads go idling in a global singleton pool
>>> and attach to each pool which needs a new thread, thereby minimizing
>>> the total number of threads.
>>>
>>> This is the implementation
>> [...]
>>
>> Just make sure to take the time to model it in a race detector.
>>
>
> The synchronization part is trivial.
> It's the state the synchronization manages that is complex.

https://youtu.be/hnRZepld6dg

On 1/27/2024 1:05 PM, Chris M. Thomasson wrote:
> On 1/25/2024 9:25 AM, Bonita Montero wrote:
>>
>> Once I've written a thread pool that has an upper limit of the number
>> threads and a timeout when idle threads end theirselfes. If you have
>> sth userpace CPU bound you'd specify the number of hardware-threads
>> as the upper limit, if you have much threads doing I/O you may go far
>> beyond since the hardware-threads aren't fully occupied anyway.
>> The problem with my initial thread pool class was that there may be
>> a large number of idle threads which could be used by other pools.
>> So I wrote a thread pool class where each pool has an upper limit of
>> the number of executing threads and there are no idle threads within
>> each pool. Instead the threads go idling in a global singleton pool
>> and attach to each pool which needs a new thread, thereby minimizing
>> the total number of threads.
>>
>> This is the implementation
>>
>> // header
>>
>> #pragma once
>> #include <thread>
>> #include <mutex>
>> #include <condition_variable>
>> #include <deque>
>> #include <functional>
>> #include <chrono>
>>
>> struct thread_pool
>
> [...]
>
>>
>> // translation unit
>>
>> #include <cassert>
>> #include "thread_pool.h"
>> #include "invoke_on_destruct.h"
>>
>> #if defined(_WIN32)
^^^^^^^^^^^^^

Why use _WIN32 here to disable all of those important warnings?

_MSC_VER instead?

Also, why disable all of those warnings in MSVC?

>>      #pragma warning(disable: 26110) // Caller failing to hold lock
>> 'lock' before calling function 'func'.
>>      #pragma warning(disable: 26111) // Caller failing to release lock
>> 'lock' before calling function 'func'.
>>      #pragma warning(disable: 26115) // Failing to release lock 'lock'
>> in function 'func'.
>>      #pragma warning(disable: 26117) // Releasing unheld lock 'lock'
>> in function 'func'.
>>      #pragma warning(disable: 26800) // Use of a moved from object:
>> 'object'.
>> #endif
>> #if defined(__llvm__)
>>      #pragma clang diagnostic ignored "-Wparentheses"
>>      #pragma clang diagnostic ignored "-Wunqualified-std-cast-call"
>> #endif
> [...]
>
> Pardon my french, but what the heck is all of this for, exactly...
>
> ?
>

Am 29.01.2024 um 23:45 schrieb Chris M. Thomasson:
> On 1/27/2024 1:05 PM, Chris M. Thomasson wrote:
>> On 1/25/2024 9:25 AM, Bonita Montero wrote:
>>>
>>> Once I've written a thread pool that has an upper limit of the number
>>> threads and a timeout when idle threads end theirselfes. If you have
>>> sth userpace CPU bound you'd specify the number of hardware-threads
>>> as the upper limit, if you have much threads doing I/O you may go far
>>> beyond since the hardware-threads aren't fully occupied anyway.
>>> The problem with my initial thread pool class was that there may be
>>> a large number of idle threads which could be used by other pools.
>>> So I wrote a thread pool class where each pool has an upper limit of
>>> the number of executing threads and there are no idle threads within
>>> each pool. Instead the threads go idling in a global singleton pool
>>> and attach to each pool which needs a new thread, thereby minimizing
>>> the total number of threads.
>>>
>>> This is the implementation
>>>
>>> // header
>>>
>>> #pragma once
>>> #include <thread>
>>> #include <mutex>
>>> #include <condition_variable>
>>> #include <deque>
>>> #include <functional>
>>> #include <chrono>
>>>
>>> struct thread_pool
>>
>> [...]
>>
>>>
>>> // translation unit
>>>
>>> #include <cassert>
>>> #include "thread_pool.h"
>>> #include "invoke_on_destruct.h"
>>>
>>> #if defined(_WIN32)
> ^^^^^^^^^^^^^
>
> Why use _WIN32 here to disable all of those important warnings?
> _MSC_VER instead?

I could change that, but clang-cl is the only compiler that recoginizes
_MSC_VER and doesn't complain about the #pragmas.

On 1/30/2024 2:44 AM, Bonita Montero wrote:
> Am 29.01.2024 um 23:45 schrieb Chris M. Thomasson:
>> On 1/27/2024 1:05 PM, Chris M. Thomasson wrote:
>>> On 1/25/2024 9:25 AM, Bonita Montero wrote:
>>>>
>>>> Once I've written a thread pool that has an upper limit of the number
>>>> threads and a timeout when idle threads end theirselfes. If you have
>>>> sth userpace CPU bound you'd specify the number of hardware-threads
>>>> as the upper limit, if you have much threads doing I/O you may go far
>>>> beyond since the hardware-threads aren't fully occupied anyway.
>>>> The problem with my initial thread pool class was that there may be
>>>> a large number of idle threads which could be used by other pools.
>>>> So I wrote a thread pool class where each pool has an upper limit of
>>>> the number of executing threads and there are no idle threads within
>>>> each pool. Instead the threads go idling in a global singleton pool
>>>> and attach to each pool which needs a new thread, thereby minimizing
>>>> the total number of threads.
>>>>
>>>> This is the implementation
>>>>
>>>> // header
>>>>
>>>> #pragma once
>>>> #include <thread>
>>>> #include <mutex>
>>>> #include <condition_variable>
>>>> #include <deque>
>>>> #include <functional>
>>>> #include <chrono>
>>>>
>>>> struct thread_pool
>>>
>>> [...]
>>>
>>>>
>>>> // translation unit
>>>>
>>>> #include <cassert>
>>>> #include "thread_pool.h"
>>>> #include "invoke_on_destruct.h"
>>>>
>>>> #if defined(_WIN32)
>> ^^^^^^^^^^^^^
>>
>> Why use _WIN32 here to disable all of those important warnings?
>> _MSC_VER instead?
>
> I could change that, but clang-cl is the only compiler that recoginizes
> _MSC_VER and doesn't complain about the #pragmas.

MSVC should define _MSC_VER, not exactly sure why clang-cl would be in
the mix. Probably due to:

https://clang.llvm.org/docs/MSVCCompatibility.html

Back in the day I used several compilers on Windows. Humm... Anyway,
what's up with all of those pragmas anyway? ;^)

Am 31.01.2024 um 00:19 schrieb Chris M. Thomasson:

> MSVC should define _MSC_VER, not exactly sure why clang-cl would be in
> the mix. Probably due to:

clang-cl does say its _MSC_VER, clang++ for Windows not.
clang-cl doesn't define __clang__, clang++ does.
But clang-cl does define __llvm__.

> https://clang.llvm.org/docs/MSVCCompatibility.html

Nothing of what I said.

On 1/31/2024 7:45 AM, Bonita Montero wrote:
> Am 31.01.2024 um 00:19 schrieb Chris M. Thomasson:
>
>> MSVC should define _MSC_VER, not exactly sure why clang-cl would be in
>> the mix. Probably due to:
>
> clang-cl does say its _MSC_VER, clang++ for Windows not.
> clang-cl doesn't define __clang__, clang++ does.
> But clang-cl does define __llvm__.
>
>> https://clang.llvm.org/docs/MSVCCompatibility.html
>
> Nothing of what I said.

I think it is relevant. Also, what's up with all of those pragmas anyway?

On 1/31/2024 12:32 PM, Chris M. Thomasson wrote:
> On 1/31/2024 7:45 AM, Bonita Montero wrote:
>> Am 31.01.2024 um 00:19 schrieb Chris M. Thomasson:
>>
>>> MSVC should define _MSC_VER, not exactly sure why clang-cl would be
>>> in the mix. Probably due to:
>>
>> clang-cl does say its _MSC_VER, clang++ for Windows not.
>> clang-cl doesn't define __clang__, clang++ does.
>> But clang-cl does define __llvm__.
>>
>>> https://clang.llvm.org/docs/MSVCCompatibility.html
>>
>> Nothing of what I said.
>
> I think it is relevant. Also, what's up with all of those pragmas anyway?
>

Humm:

https://youtu.be/hAMQIvEtcJM

On 1/31/2024 6:35 PM, Chris M. Thomasson wrote:
> On 1/31/2024 12:32 PM, Chris M. Thomasson wrote:
>> On 1/31/2024 7:45 AM, Bonita Montero wrote:
>>> Am 31.01.2024 um 00:19 schrieb Chris M. Thomasson:
>>>
>>>> MSVC should define _MSC_VER, not exactly sure why clang-cl would be
>>>> in the mix. Probably due to:
>>>
>>> clang-cl does say its _MSC_VER, clang++ for Windows not.
>>> clang-cl doesn't define __clang__, clang++ does.
>>> But clang-cl does define __llvm__.
>>>
>>>> https://clang.llvm.org/docs/MSVCCompatibility.html
>>>
>>> Nothing of what I said.
>>
>> I think it is relevant. Also, what's up with all of those pragmas anyway?
>>
>
> Humm:
>
> https://youtu.be/hAMQIvEtcJM

Your pragmas also make me think of:

https://youtu.be/i_6zPIWQaUI

Am 31.01.2024 um 21:32 schrieb Chris M. Thomasson:

> I think it is relevant. Also, what's up with all of those pragmas anyway?

They suppress warnings and the type of warning is in the commment.

On 2/1/2024 2:18 AM, Bonita Montero wrote:
> Am 31.01.2024 um 21:32 schrieb Chris M. Thomasson:
>
>> I think it is relevant. Also, what's up with all of those pragmas anyway?
>
> They suppress warnings and the type of warning is in the commment.
>
>

Oh, I know all about that. But why in the world would anybody want to
suppress warnings that deal with:
_________________
#pragma warning(disable: 26110) // Caller failing to hold lock 'lock'
before calling function 'func'.

#pragma warning(disable: 26111) // Caller failing to release lock
'lock' before calling function 'func'.

#pragma warning(disable: 26115) // Failing to release lock 'lock'
in function 'func'.

#pragma warning(disable: 26117) // Releasing unheld lock 'lock' in
function 'func'.

#pragma warning(disable: 26800) // Use of a moved from object:
'object'.
_________________

Wow! ;^o

On 2/1/2024 12:05 PM, Chris M. Thomasson wrote:
> On 2/1/2024 2:18 AM, Bonita Montero wrote:
>> Am 31.01.2024 um 21:32 schrieb Chris M. Thomasson:
>>
>>> I think it is relevant. Also, what's up with all of those pragmas
>>> anyway?
>>
>> They suppress warnings and the type of warning is in the commment.
>>
>>
>
> Oh, I know all about that. But why in the world would anybody want to
> suppress warnings that deal with:
> _________________
>  #pragma warning(disable: 26110) // Caller failing to hold lock 'lock'
> before calling function 'func'.
>
>      #pragma warning(disable: 26111) // Caller failing to release lock
> 'lock' before calling function 'func'.
>
>      #pragma warning(disable: 26115) // Failing to release lock 'lock'
> in function 'func'.
>
>      #pragma warning(disable: 26117) // Releasing unheld lock 'lock' in
> function 'func'.
>
>      #pragma warning(disable: 26800) // Use of a moved from object:
> 'object'.
> _________________
>
> Wow! ;^o

[SARCASM]
Because Bonita's code is perfect and you're a doofus, duh!
[/SARCASM]

On 2/1/2024 12:23 PM, red floyd wrote:
> On 2/1/2024 12:05 PM, Chris M. Thomasson wrote:
>> On 2/1/2024 2:18 AM, Bonita Montero wrote:
>>> Am 31.01.2024 um 21:32 schrieb Chris M. Thomasson:
>>>
>>>> I think it is relevant. Also, what's up with all of those pragmas
>>>> anyway?
>>>
>>> They suppress warnings and the type of warning is in the commment.
>>>
>>>
>>
>> Oh, I know all about that. But why in the world would anybody want to
>> suppress warnings that deal with:
>> _________________
>>   #pragma warning(disable: 26110) // Caller failing to hold lock
>> 'lock' before calling function 'func'.
>>
>>       #pragma warning(disable: 26111) // Caller failing to release
>> lock 'lock' before calling function 'func'.
>>
>>       #pragma warning(disable: 26115) // Failing to release lock
>> 'lock' in function 'func'.
>>
>>       #pragma warning(disable: 26117) // Releasing unheld lock 'lock'
>> in function 'func'.
>>
>>       #pragma warning(disable: 26800) // Use of a moved from object:
>> 'object'.
>> _________________
>>
>> Wow! ;^o
>
> [SARCASM]
> Because Bonita's code is perfect and you're a doofus, duh!
> [/SARCASM]
>

YIKES! lol. Thanks for the laugh! :^D

These warnings are, ummm, well, _very_ important. I still don't know why
the Bonita suppresses them.

Am 01.02.2024 um 21:05 schrieb Chris M. Thomasson:

> Oh, I know all about that. But why in the world would anybody want to
> suppress warnings that deal with:
> _________________
>  #pragma warning(disable: 26110) // Caller failing to hold lock 'lock'
> before calling function 'func'.
>
>      #pragma warning(disable: 26111) // Caller failing to release lock
> 'lock' before calling function 'func'.
>
>      #pragma warning(disable: 26115) // Failing to release lock 'lock'
> in function 'func'.
>
>      #pragma warning(disable: 26117) // Releasing unheld lock 'lock' in
> function 'func'.
>
>      #pragma warning(disable: 26800) // Use of a moved from object:
> 'object'.
> _________________
>
> Wow! ;^o

These warnings appear where they don't make sense, f.e. the compiler
doesn't see that I'm actually holding the lock.

On 2/3/2024 11:04 AM, Bonita Montero wrote:
> Am 01.02.2024 um 21:05 schrieb Chris M. Thomasson:
>
>> Oh, I know all about that. But why in the world would anybody want to
>> suppress warnings that deal with:
>> _________________
>>   #pragma warning(disable: 26110) // Caller failing to hold lock
>> 'lock' before calling function 'func'.
>>
>>       #pragma warning(disable: 26111) // Caller failing to release
>> lock 'lock' before calling function 'func'.
>>
>>       #pragma warning(disable: 26115) // Failing to release lock
>> 'lock' in function 'func'.
>>
>>       #pragma warning(disable: 26117) // Releasing unheld lock 'lock'
>> in function 'func'.
>>
>>       #pragma warning(disable: 26800) // Use of a moved from object:
>> 'object'.
>> _________________
>>
>> Wow! ;^o
>
> These warnings appear where they don't make sense, f.e. the compiler
> doesn't see that I'm actually holding the lock.
>

Hummm... You threw me for a loop here... What exactly do you mean? Show
me a condensed example. Those warnings are there for a reason... You
really need to model it in a race detector. Relacy is a fun one.

Am 03.02.2024 um 21:05 schrieb Chris M. Thomasson:

> Hummm... You threw me for a loop here... What exactly do you mean? Show
> me a condensed example. Those warnings are there for a reason... You
> really need to model it in a race detector. Relacy is a fun one.

The code doesn't need any race detector, the synchronization part is
trivial.

On 2/3/2024 8:58 PM, Bonita Montero wrote:
> Am 03.02.2024 um 21:05 schrieb Chris M. Thomasson:
>
>> Hummm... You threw me for a loop here... What exactly do you mean?
>> Show me a condensed example. Those warnings are there for a reason...
>> You really need to model it in a race detector. Relacy is a fun one.
>
> The code doesn't need any race detector, the synchronization part is
> trivial.
>

What happens if you turn off all of those very important warnings?

Am 04.02.2024 um 06:30 schrieb Chris M. Thomasson:
> On 2/3/2024 8:58 PM, Bonita Montero wrote:
>> Am 03.02.2024 um 21:05 schrieb Chris M. Thomasson:
>>
>>> Hummm... You threw me for a loop here... What exactly do you mean?
>>> Show me a condensed example. Those warnings are there for a reason...
>>> You really need to model it in a race detector. Relacy is a fun one.
>>
>> The code doesn't need any race detector, the synchronization part is
>> trivial.
>>
>
> What happens if you turn off all of those very important warnings?

What a question ...
I get incorrect warnings while compiling.