Rocksolid Light

Welcome to novaBBS (click a section below)

mail  files  register  newsreader  groups  login

Message-ID:  

grep me no patterns and I'll tell you no lines.


devel / comp.lang.c++ / The ultimate thread pool

SubjectAuthor
* The ultimate thread poolBonita Montero
+* Re: The ultimate thread poolChris M. Thomasson
|+* Re: The ultimate thread poolBonita Montero
||+- Re: The ultimate thread poolChris M. Thomasson
||`* Re: The ultimate thread poolChris M. Thomasson
|| `- Re: The ultimate thread poolChris M. Thomasson
|`* Re: The ultimate thread poolBonita Montero
| `- Re: The ultimate thread poolChris M. Thomasson
`* Re: The ultimate thread poolChris M. Thomasson
 `* Re: The ultimate thread poolChris M. Thomasson
  `* Re: The ultimate thread poolBonita Montero
   `* Re: The ultimate thread poolChris M. Thomasson
    `* Re: The ultimate thread poolBonita Montero
     `* Re: The ultimate thread poolChris M. Thomasson
      +* Re: The ultimate thread poolChris M. Thomasson
      |`- Re: The ultimate thread poolChris M. Thomasson
      `* Re: The ultimate thread poolBonita Montero
       `* Re: The ultimate thread poolChris M. Thomasson
        +* Re: The ultimate thread poolred floyd
        |`- Re: The ultimate thread poolChris M. Thomasson
        `* Re: The ultimate thread poolBonita Montero
         `* Re: The ultimate thread poolChris M. Thomasson
          `* Re: The ultimate thread poolBonita Montero
           `* Re: The ultimate thread poolChris M. Thomasson
            `* Re: The ultimate thread poolBonita Montero
             +* Re: The ultimate thread poolChris M. Thomasson
             |`* Re: The ultimate thread poolBonita Montero
             | `* Re: The ultimate thread poolChris M. Thomasson
             |  `* Re: The ultimate thread poolBonita Montero
             |   +* Re: The ultimate thread poolChris M. Thomasson
             |   |+- Re: The ultimate thread poolChris M. Thomasson
             |   |+- Re: The ultimate thread poolChris M. Thomasson
             |   |`- Re: The ultimate thread poolBonita Montero
             |   `* Re: The ultimate thread poolChris M. Thomasson
             |    +* Re: The ultimate thread poolBonita Montero
             |    |`* Re: The ultimate thread poolChris M. Thomasson
             |    | `* Re: The ultimate thread poolBonita Montero
             |    |  `- Re: The ultimate thread poolChris M. Thomasson
             |    `* Re: The ultimate thread poolBonita Montero
             |     `* Re: The ultimate thread poolChris M. Thomasson
             |      `* Re: The ultimate thread poolBonita Montero
             |       `* Re: The ultimate thread poolChris M. Thomasson
             |        `* Re: The ultimate thread poolBonita Montero
             |         +- Re: The ultimate thread poolChris M. Thomasson
             |         `* Re: The ultimate thread poolChris M. Thomasson
             |          `* Re: The ultimate thread poolBonita Montero
             |           `* Re: The ultimate thread poolChris M. Thomasson
             |            `* Re: The ultimate thread poolBonita Montero
             |             `- Re: The ultimate thread poolChris M. Thomasson
             `- Re: The ultimate thread poolChris M. Thomasson

Pages:12
The ultimate thread pool

<uou5ir$2cuko$2@raubtier-asyl.eternal-september.org>

  copy mid

https://www.novabbs.com/devel/article-flat.php?id=3079&group=comp.lang.c%2B%2B#3079

  copy link   Newsgroups: comp.lang.c++
Path: i2pn2.org!rocksolid2!news.neodome.net!news.mixmin.net!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!raubtier-asyl.eternal-september.org!.POSTED!not-for-mail
From: Bonita.M...@gmail.com (Bonita Montero)
Newsgroups: comp.lang.c++
Subject: The ultimate thread pool
Date: Thu, 25 Jan 2024 18:25:48 +0100
Organization: A noiseless patient Spider
Lines: 561
Message-ID: <uou5ir$2cuko$2@raubtier-asyl.eternal-september.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Injection-Date: Thu, 25 Jan 2024 17:25:47 -0000 (UTC)
Injection-Info: raubtier-asyl.eternal-september.org; posting-host="ad0645c524da5c98158469efd5e7da33";
logging-data="2521752"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1+q/E63szeGa8qK2tU+tE6BPz7xrQmar1A="
User-Agent: Mozilla Thunderbird
Cancel-Lock: sha1:ZJExHsJu8Bog63ISnuDLjBIMrgk=
Content-Language: de-DE
 by: Bonita Montero - Thu, 25 Jan 2024 17:25 UTC

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();
}
}


Click here to read the complete article
Re: The ultimate thread pool

<uoucub$2e4qs$2@dont-email.me>

  copy mid

https://www.novabbs.com/devel/article-flat.php?id=3080&group=comp.lang.c%2B%2B#3080

  copy link   Newsgroups: comp.lang.c++
Path: i2pn2.org!rocksolid2!news.neodome.net!news.mixmin.net!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail
From: chris.m....@gmail.com (Chris M. Thomasson)
Newsgroups: comp.lang.c++
Subject: Re: The ultimate thread pool
Date: Thu, 25 Jan 2024 11:31:23 -0800
Organization: A noiseless patient Spider
Lines: 20
Message-ID: <uoucub$2e4qs$2@dont-email.me>
References: <uou5ir$2cuko$2@raubtier-asyl.eternal-september.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Injection-Date: Thu, 25 Jan 2024 19:31:24 -0000 (UTC)
Injection-Info: dont-email.me; posting-host="7f23c2054aa5a15fad4661d44b257fda";
logging-data="2560860"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1/j9bO9VMxsIeh/8DewCqQ5eFhnPbORkQQ="
User-Agent: Mozilla Thunderbird
Cancel-Lock: sha1:r9LZuxYg3rrYjesl5HjOs0b4ci8=
Content-Language: en-US
In-Reply-To: <uou5ir$2cuko$2@raubtier-asyl.eternal-september.org>
 by: Chris M. Thomasson - Thu, 25 Jan 2024 19:31 UTC

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.

Re: The ultimate thread pool

<uovb89$2mgib$1@raubtier-asyl.eternal-september.org>

  copy mid

https://www.novabbs.com/devel/article-flat.php?id=3081&group=comp.lang.c%2B%2B#3081

  copy link   Newsgroups: comp.lang.c++
Path: i2pn2.org!i2pn.org!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!raubtier-asyl.eternal-september.org!.POSTED!not-for-mail
From: Bonita.M...@gmail.com (Bonita Montero)
Newsgroups: comp.lang.c++
Subject: Re: The ultimate thread pool
Date: Fri, 26 Jan 2024 05:08:42 +0100
Organization: A noiseless patient Spider
Lines: 24
Message-ID: <uovb89$2mgib$1@raubtier-asyl.eternal-september.org>
References: <uou5ir$2cuko$2@raubtier-asyl.eternal-september.org>
<uoucub$2e4qs$2@dont-email.me>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Injection-Date: Fri, 26 Jan 2024 04:08:41 -0000 (UTC)
Injection-Info: raubtier-asyl.eternal-september.org; posting-host="b2328b3c5ab0e555431b41f7fdeaec8d";
logging-data="2835019"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1/6S4LY9iZzKe+LlMVtHExkt0P9qEJm3/M="
User-Agent: Mozilla Thunderbird
Cancel-Lock: sha1:c+ofxP+4SsVWe5WpCt0D9/ofjvY=
In-Reply-To: <uoucub$2e4qs$2@dont-email.me>
Content-Language: de-DE
 by: Bonita Montero - Fri, 26 Jan 2024 04:08 UTC

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

Re: The ultimate thread pool

<up1lek$337tp$3@dont-email.me>

  copy mid

https://www.novabbs.com/devel/article-flat.php?id=3082&group=comp.lang.c%2B%2B#3082

  copy link   Newsgroups: comp.lang.c++
Path: i2pn2.org!i2pn.org!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail
From: chris.m....@gmail.com (Chris M. Thomasson)
Newsgroups: comp.lang.c++
Subject: Re: The ultimate thread pool
Date: Fri, 26 Jan 2024 17:15:00 -0800
Organization: A noiseless patient Spider
Lines: 28
Message-ID: <up1lek$337tp$3@dont-email.me>
References: <uou5ir$2cuko$2@raubtier-asyl.eternal-september.org>
<uoucub$2e4qs$2@dont-email.me>
<uovb89$2mgib$1@raubtier-asyl.eternal-september.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Injection-Date: Sat, 27 Jan 2024 01:15:00 -0000 (UTC)
Injection-Info: dont-email.me; posting-host="4de68a687a399c61b3fcd74392800b9b";
logging-data="3252153"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1+WEkcI+OyuRyBBkJa6i3v1WrgbFkT+DS8="
User-Agent: Mozilla Thunderbird
Cancel-Lock: sha1:X2mq0VQnZeayi45beXfo5NAtW0I=
Content-Language: en-US
In-Reply-To: <uovb89$2mgib$1@raubtier-asyl.eternal-september.org>
 by: Chris M. Thomasson - Sat, 27 Jan 2024 01:15 UTC

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? :^)

Re: The ultimate thread pool

<up1t08$382mv$1@dont-email.me>

  copy mid

https://www.novabbs.com/devel/article-flat.php?id=3083&group=comp.lang.c%2B%2B#3083

  copy link   Newsgroups: comp.lang.c++
Path: i2pn2.org!i2pn.org!news.bbs.nz!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail
From: chris.m....@gmail.com (Chris M. Thomasson)
Newsgroups: comp.lang.c++
Subject: Re: The ultimate thread pool
Date: Fri, 26 Jan 2024 19:23:52 -0800
Organization: A noiseless patient Spider
Lines: 33
Message-ID: <up1t08$382mv$1@dont-email.me>
References: <uou5ir$2cuko$2@raubtier-asyl.eternal-september.org>
<uoucub$2e4qs$2@dont-email.me>
<uovb89$2mgib$1@raubtier-asyl.eternal-september.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Injection-Date: Sat, 27 Jan 2024 03:23:52 -0000 (UTC)
Injection-Info: dont-email.me; posting-host="4de68a687a399c61b3fcd74392800b9b";
logging-data="3410655"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX19Fc7Gcy5+tY0WQZAFh6jBJfHtcUVgl4BM="
User-Agent: Mozilla Thunderbird
Cancel-Lock: sha1:0xNIlLI8qrkqfMpB/Bm6E45OAOw=
Content-Language: en-US
In-Reply-To: <uovb89$2mgib$1@raubtier-asyl.eternal-september.org>
 by: Chris M. Thomasson - Sat, 27 Jan 2024 03:23 UTC

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? :^)

Re: The ultimate thread pool

<up1t28$382mv$2@dont-email.me>

  copy mid

https://www.novabbs.com/devel/article-flat.php?id=3084&group=comp.lang.c%2B%2B#3084

  copy link   Newsgroups: comp.lang.c++
Path: i2pn2.org!i2pn.org!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail
From: chris.m....@gmail.com (Chris M. Thomasson)
Newsgroups: comp.lang.c++
Subject: Re: The ultimate thread pool
Date: Fri, 26 Jan 2024 19:24:55 -0800
Organization: A noiseless patient Spider
Lines: 36
Message-ID: <up1t28$382mv$2@dont-email.me>
References: <uou5ir$2cuko$2@raubtier-asyl.eternal-september.org>
<uoucub$2e4qs$2@dont-email.me>
<uovb89$2mgib$1@raubtier-asyl.eternal-september.org>
<up1t08$382mv$1@dont-email.me>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Injection-Date: Sat, 27 Jan 2024 03:24:56 -0000 (UTC)
Injection-Info: dont-email.me; posting-host="4de68a687a399c61b3fcd74392800b9b";
logging-data="3410655"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX19eNuBGX7BsT2mD5W6DAe1MFzQmMLJcLMg="
User-Agent: Mozilla Thunderbird
Cancel-Lock: sha1:PKkN7SqgTRrq8VsYxd6CZ4XDAic=
In-Reply-To: <up1t08$382mv$1@dont-email.me>
Content-Language: en-US
 by: Chris M. Thomasson - Sat, 27 Jan 2024 03:24 UTC

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

Re: The ultimate thread pool

<up2fe7$3agdc$1@raubtier-asyl.eternal-september.org>

  copy mid

https://www.novabbs.com/devel/article-flat.php?id=3086&group=comp.lang.c%2B%2B#3086

  copy link   Newsgroups: comp.lang.c++
Path: i2pn2.org!i2pn.org!news.niel.me!news.gegeweb.eu!gegeweb.org!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!raubtier-asyl.eternal-september.org!.POSTED!not-for-mail
From: Bonita.M...@gmail.com (Bonita Montero)
Newsgroups: comp.lang.c++
Subject: Re: The ultimate thread pool
Date: Sat, 27 Jan 2024 09:38:34 +0100
Organization: A noiseless patient Spider
Lines: 24
Message-ID: <up2fe7$3agdc$1@raubtier-asyl.eternal-september.org>
References: <uou5ir$2cuko$2@raubtier-asyl.eternal-september.org>
<uoucub$2e4qs$2@dont-email.me>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Injection-Date: Sat, 27 Jan 2024 08:38:31 -0000 (UTC)
Injection-Info: raubtier-asyl.eternal-september.org; posting-host="a37ddde09c37fcbd64529f5bdf927658";
logging-data="3490220"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX189qLbvX8ABuUc/ON6kOwqFx7WkOJ+d5do="
User-Agent: Mozilla Thunderbird
Cancel-Lock: sha1:pOfytZe6GqZQofa0XspLzRQRAn8=
Content-Language: de-DE
In-Reply-To: <uoucub$2e4qs$2@dont-email.me>
 by: Bonita Montero - Sat, 27 Jan 2024 08:38 UTC

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.

Re: The ultimate thread pool

<up3r6t$3hjng$1@dont-email.me>

  copy mid

https://www.novabbs.com/devel/article-flat.php?id=3087&group=comp.lang.c%2B%2B#3087

  copy link   Newsgroups: comp.lang.c++
Path: i2pn2.org!i2pn.org!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail
From: chris.m....@gmail.com (Chris M. Thomasson)
Newsgroups: comp.lang.c++
Subject: Re: The ultimate thread pool
Date: Sat, 27 Jan 2024 13:05:33 -0800
Organization: A noiseless patient Spider
Lines: 60
Message-ID: <up3r6t$3hjng$1@dont-email.me>
References: <uou5ir$2cuko$2@raubtier-asyl.eternal-september.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Date: Sat, 27 Jan 2024 21:05:33 -0000 (UTC)
Injection-Info: dont-email.me; posting-host="4de68a687a399c61b3fcd74392800b9b";
logging-data="3722992"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX191zEExi7VsGoWJcn3jW0Ngwn2RPunAjNo="
User-Agent: Mozilla Thunderbird
Cancel-Lock: sha1:rYBkdBeZeT1XBbDFQFXC6SvZPA0=
In-Reply-To: <uou5ir$2cuko$2@raubtier-asyl.eternal-september.org>
Content-Language: en-US
 by: Chris M. Thomasson - Sat, 27 Jan 2024 21:05 UTC

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

?

Re: The ultimate thread pool

<up4nlo$3pclu$1@dont-email.me>

  copy mid

https://www.novabbs.com/devel/article-flat.php?id=3088&group=comp.lang.c%2B%2B#3088

  copy link   Newsgroups: comp.lang.c++
Path: i2pn2.org!i2pn.org!weretis.net!feeder6.news.weretis.net!feeder8.news.weretis.net!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail
From: chris.m....@gmail.com (Chris M. Thomasson)
Newsgroups: comp.lang.c++
Subject: Re: The ultimate thread pool
Date: Sat, 27 Jan 2024 21:11:20 -0800
Organization: A noiseless patient Spider
Lines: 27
Message-ID: <up4nlo$3pclu$1@dont-email.me>
References: <uou5ir$2cuko$2@raubtier-asyl.eternal-september.org>
<uoucub$2e4qs$2@dont-email.me>
<up2fe7$3agdc$1@raubtier-asyl.eternal-september.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Injection-Date: Sun, 28 Jan 2024 05:11:21 -0000 (UTC)
Injection-Info: dont-email.me; posting-host="9fe4cfb1338e5b9f0f0e57f1cea759c7";
logging-data="3977918"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1+mjFNa+5/2sXqcJw2aT8T3iL6RnxzBcAI="
User-Agent: Mozilla Thunderbird
Cancel-Lock: sha1:7rjmBYWsfUC6EmnkGWcj0LCu/1c=
In-Reply-To: <up2fe7$3agdc$1@raubtier-asyl.eternal-september.org>
Content-Language: en-US
 by: Chris M. Thomasson - Sun, 28 Jan 2024 05:11 UTC

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

Re: The ultimate thread pool

<up99ph$l7gv$1@dont-email.me>

  copy mid

https://www.novabbs.com/devel/article-flat.php?id=3096&group=comp.lang.c%2B%2B#3096

  copy link   Newsgroups: comp.lang.c++
Path: i2pn2.org!i2pn.org!nntp.comgw.net!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail
From: chris.m....@gmail.com (Chris M. Thomasson)
Newsgroups: comp.lang.c++
Subject: Re: The ultimate thread pool
Date: Mon, 29 Jan 2024 14:45:05 -0800
Organization: A noiseless patient Spider
Lines: 71
Message-ID: <up99ph$l7gv$1@dont-email.me>
References: <uou5ir$2cuko$2@raubtier-asyl.eternal-september.org>
<up3r6t$3hjng$1@dont-email.me>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Date: Mon, 29 Jan 2024 22:45:05 -0000 (UTC)
Injection-Info: dont-email.me; posting-host="79e47a7daf77a3dc87926c1beb8fd8a3";
logging-data="695839"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1+zyLlf1w9ewJQxsAlbYYqqf3oY2JNsWOE="
User-Agent: Mozilla Thunderbird
Cancel-Lock: sha1:cH1xk07H3CyJQ+/9W0yBojwJjJo=
In-Reply-To: <up3r6t$3hjng$1@dont-email.me>
Content-Language: en-US
 by: Chris M. Thomasson - Mon, 29 Jan 2024 22:45 UTC

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

Re: The ultimate thread pool

<upajva$uvcc$1@raubtier-asyl.eternal-september.org>

  copy mid

https://www.novabbs.com/devel/article-flat.php?id=3097&group=comp.lang.c%2B%2B#3097

  copy link   Newsgroups: comp.lang.c++
Path: i2pn2.org!i2pn.org!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!raubtier-asyl.eternal-september.org!.POSTED!not-for-mail
From: Bonita.M...@gmail.com (Bonita Montero)
Newsgroups: comp.lang.c++
Subject: Re: The ultimate thread pool
Date: Tue, 30 Jan 2024 11:44:59 +0100
Organization: A noiseless patient Spider
Lines: 48
Message-ID: <upajva$uvcc$1@raubtier-asyl.eternal-september.org>
References: <uou5ir$2cuko$2@raubtier-asyl.eternal-september.org>
<up3r6t$3hjng$1@dont-email.me> <up99ph$l7gv$1@dont-email.me>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Injection-Date: Tue, 30 Jan 2024 10:44:58 -0000 (UTC)
Injection-Info: raubtier-asyl.eternal-september.org; posting-host="79fa68310583cf528f9b017a6ae1a240";
logging-data="1015180"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1/sJsyJbiKipf7O0vlibbNAyc9LH/AgVmg="
User-Agent: Mozilla Thunderbird
Cancel-Lock: sha1:MlcK+3lWYuNFjONK65viCHlmQoA=
In-Reply-To: <up99ph$l7gv$1@dont-email.me>
Content-Language: de-DE
 by: Bonita Montero - Tue, 30 Jan 2024 10:44 UTC

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.

Re: The ultimate thread pool

<upc058$16gik$1@dont-email.me>

  copy mid

https://www.novabbs.com/devel/article-flat.php?id=3099&group=comp.lang.c%2B%2B#3099

  copy link   Newsgroups: comp.lang.c++
Path: i2pn2.org!i2pn.org!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail
From: chris.m....@gmail.com (Chris M. Thomasson)
Newsgroups: comp.lang.c++
Subject: Re: The ultimate thread pool
Date: Tue, 30 Jan 2024 15:19:04 -0800
Organization: A noiseless patient Spider
Lines: 57
Message-ID: <upc058$16gik$1@dont-email.me>
References: <uou5ir$2cuko$2@raubtier-asyl.eternal-september.org>
<up3r6t$3hjng$1@dont-email.me> <up99ph$l7gv$1@dont-email.me>
<upajva$uvcc$1@raubtier-asyl.eternal-september.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Injection-Date: Tue, 30 Jan 2024 23:19:04 -0000 (UTC)
Injection-Info: dont-email.me; posting-host="86739c35754819de56193aa55af5332a";
logging-data="1262164"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1/Bs3XATMnK4gydwWPdk0WctYmfqd9zHcw="
User-Agent: Mozilla Thunderbird
Cancel-Lock: sha1:wW5xXw+pgqB3lpGmw7qoBpRPiDw=
In-Reply-To: <upajva$uvcc$1@raubtier-asyl.eternal-september.org>
Content-Language: en-US
 by: Chris M. Thomasson - Tue, 30 Jan 2024 23:19 UTC

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? ;^)

Re: The ultimate thread pool

<updpvf$1j50l$1@raubtier-asyl.eternal-september.org>

  copy mid

https://www.novabbs.com/devel/article-flat.php?id=3101&group=comp.lang.c%2B%2B#3101

  copy link   Newsgroups: comp.lang.c++
Path: i2pn2.org!i2pn.org!nntp.comgw.net!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!raubtier-asyl.eternal-september.org!.POSTED!not-for-mail
From: Bonita.M...@gmail.com (Bonita Montero)
Newsgroups: comp.lang.c++
Subject: Re: The ultimate thread pool
Date: Wed, 31 Jan 2024 16:45:53 +0100
Organization: A noiseless patient Spider
Lines: 14
Message-ID: <updpvf$1j50l$1@raubtier-asyl.eternal-september.org>
References: <uou5ir$2cuko$2@raubtier-asyl.eternal-september.org>
<up3r6t$3hjng$1@dont-email.me> <up99ph$l7gv$1@dont-email.me>
<upajva$uvcc$1@raubtier-asyl.eternal-september.org>
<upc058$16gik$1@dont-email.me>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Injection-Date: Wed, 31 Jan 2024 15:45:51 -0000 (UTC)
Injection-Info: raubtier-asyl.eternal-september.org; posting-host="8635ce104363d8a06aa0d72ff6020067";
logging-data="1676309"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1+ZtJZ3whopynkKV/+jPnVKdoXin49/8xY="
User-Agent: Mozilla Thunderbird
Cancel-Lock: sha1:J3i/SOH2Wex9KxchBZNxijpNK8o=
In-Reply-To: <upc058$16gik$1@dont-email.me>
Content-Language: de-DE
 by: Bonita Montero - Wed, 31 Jan 2024 15:45 UTC

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.

Re: The ultimate thread pool

<upeao1$1m29s$1@dont-email.me>

  copy mid

https://www.novabbs.com/devel/article-flat.php?id=3103&group=comp.lang.c%2B%2B#3103

  copy link   Newsgroups: comp.lang.c++
Path: i2pn2.org!i2pn.org!news.bbs.nz!newsfeed.xs3.de!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail
From: chris.m....@gmail.com (Chris M. Thomasson)
Newsgroups: comp.lang.c++
Subject: Re: The ultimate thread pool
Date: Wed, 31 Jan 2024 12:32:01 -0800
Organization: A noiseless patient Spider
Lines: 16
Message-ID: <upeao1$1m29s$1@dont-email.me>
References: <uou5ir$2cuko$2@raubtier-asyl.eternal-september.org>
<up3r6t$3hjng$1@dont-email.me> <up99ph$l7gv$1@dont-email.me>
<upajva$uvcc$1@raubtier-asyl.eternal-september.org>
<upc058$16gik$1@dont-email.me>
<updpvf$1j50l$1@raubtier-asyl.eternal-september.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Injection-Date: Wed, 31 Jan 2024 20:32:01 -0000 (UTC)
Injection-Info: dont-email.me; posting-host="86739c35754819de56193aa55af5332a";
logging-data="1771836"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1/28eUNgwjdr6ik3lAtTBEHAuvhcDcP9EQ="
User-Agent: Mozilla Thunderbird
Cancel-Lock: sha1:TtFjgGITjt7IGsEcuuDVcRO/KS8=
In-Reply-To: <updpvf$1j50l$1@raubtier-asyl.eternal-september.org>
Content-Language: en-US
 by: Chris M. Thomasson - Wed, 31 Jan 2024 20:32 UTC

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?

Re: The ultimate thread pool

<upf015$1t4ao$1@dont-email.me>

  copy mid

https://www.novabbs.com/devel/article-flat.php?id=3104&group=comp.lang.c%2B%2B#3104

  copy link   Newsgroups: comp.lang.c++
Path: i2pn2.org!i2pn.org!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail
From: chris.m....@gmail.com (Chris M. Thomasson)
Newsgroups: comp.lang.c++
Subject: Re: The ultimate thread pool
Date: Wed, 31 Jan 2024 18:35:17 -0800
Organization: A noiseless patient Spider
Lines: 21
Message-ID: <upf015$1t4ao$1@dont-email.me>
References: <uou5ir$2cuko$2@raubtier-asyl.eternal-september.org>
<up3r6t$3hjng$1@dont-email.me> <up99ph$l7gv$1@dont-email.me>
<upajva$uvcc$1@raubtier-asyl.eternal-september.org>
<upc058$16gik$1@dont-email.me>
<updpvf$1j50l$1@raubtier-asyl.eternal-september.org>
<upeao1$1m29s$1@dont-email.me>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Injection-Date: Thu, 1 Feb 2024 02:35:17 -0000 (UTC)
Injection-Info: dont-email.me; posting-host="e5db24bf58349e0f24b4ca76196085dd";
logging-data="2003288"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1/G/pYbpz1k0sHDnKTYTV5C/lgGQfT/PRM="
User-Agent: Mozilla Thunderbird
Cancel-Lock: sha1:Hy7iPb4yEcUlcRE45XCNLNnee6A=
Content-Language: en-US
In-Reply-To: <upeao1$1m29s$1@dont-email.me>
 by: Chris M. Thomasson - Thu, 1 Feb 2024 02:35 UTC

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

Re: The ultimate thread pool

<upf22o$1td2d$1@dont-email.me>

  copy mid

https://www.novabbs.com/devel/article-flat.php?id=3105&group=comp.lang.c%2B%2B#3105

  copy link   Newsgroups: comp.lang.c++
Path: i2pn2.org!i2pn.org!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail
From: chris.m....@gmail.com (Chris M. Thomasson)
Newsgroups: comp.lang.c++
Subject: Re: The ultimate thread pool
Date: Wed, 31 Jan 2024 19:10:11 -0800
Organization: A noiseless patient Spider
Lines: 26
Message-ID: <upf22o$1td2d$1@dont-email.me>
References: <uou5ir$2cuko$2@raubtier-asyl.eternal-september.org>
<up3r6t$3hjng$1@dont-email.me> <up99ph$l7gv$1@dont-email.me>
<upajva$uvcc$1@raubtier-asyl.eternal-september.org>
<upc058$16gik$1@dont-email.me>
<updpvf$1j50l$1@raubtier-asyl.eternal-september.org>
<upeao1$1m29s$1@dont-email.me> <upf015$1t4ao$1@dont-email.me>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Injection-Date: Thu, 1 Feb 2024 03:10:16 -0000 (UTC)
Injection-Info: dont-email.me; posting-host="e5db24bf58349e0f24b4ca76196085dd";
logging-data="2012237"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX18VP8euPGtgH7IwN2irS1ZfTovdkrb0tLI="
User-Agent: Mozilla Thunderbird
Cancel-Lock: sha1:AtZej8hHqVQVG5ZfYro/dutuLjM=
In-Reply-To: <upf015$1t4ao$1@dont-email.me>
Content-Language: en-US
 by: Chris M. Thomasson - Thu, 1 Feb 2024 03:10 UTC

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

Re: The ultimate thread pool

<upfr60$2114k$1@raubtier-asyl.eternal-september.org>

  copy mid

https://www.novabbs.com/devel/article-flat.php?id=3106&group=comp.lang.c%2B%2B#3106

  copy link   Newsgroups: comp.lang.c++
Path: i2pn2.org!i2pn.org!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!raubtier-asyl.eternal-september.org!.POSTED!not-for-mail
From: Bonita.M...@gmail.com (Bonita Montero)
Newsgroups: comp.lang.c++
Subject: Re: The ultimate thread pool
Date: Thu, 1 Feb 2024 11:18:42 +0100
Organization: A noiseless patient Spider
Lines: 7
Message-ID: <upfr60$2114k$1@raubtier-asyl.eternal-september.org>
References: <uou5ir$2cuko$2@raubtier-asyl.eternal-september.org>
<up3r6t$3hjng$1@dont-email.me> <up99ph$l7gv$1@dont-email.me>
<upajva$uvcc$1@raubtier-asyl.eternal-september.org>
<upc058$16gik$1@dont-email.me>
<updpvf$1j50l$1@raubtier-asyl.eternal-september.org>
<upeao1$1m29s$1@dont-email.me>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Injection-Date: Thu, 1 Feb 2024 10:18:40 -0000 (UTC)
Injection-Info: raubtier-asyl.eternal-september.org; posting-host="d17211094311263aa64e09b05b63c357";
logging-data="2131092"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX18zGGv5W+a7m+E7xECDMy4JmtCCufJCReA="
User-Agent: Mozilla Thunderbird
Cancel-Lock: sha1:MOl/NZppwxdCnjb65S8oNNdh65E=
Content-Language: de-DE
In-Reply-To: <upeao1$1m29s$1@dont-email.me>
 by: Bonita Montero - Thu, 1 Feb 2024 10:18 UTC

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.

Re: The ultimate thread pool

<upgti9$278rd$1@dont-email.me>

  copy mid

https://www.novabbs.com/devel/article-flat.php?id=3107&group=comp.lang.c%2B%2B#3107

  copy link   Newsgroups: comp.lang.c++
Path: i2pn2.org!i2pn.org!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail
From: chris.m....@gmail.com (Chris M. Thomasson)
Newsgroups: comp.lang.c++
Subject: Re: The ultimate thread pool
Date: Thu, 1 Feb 2024 12:05:29 -0800
Organization: A noiseless patient Spider
Lines: 29
Message-ID: <upgti9$278rd$1@dont-email.me>
References: <uou5ir$2cuko$2@raubtier-asyl.eternal-september.org>
<up3r6t$3hjng$1@dont-email.me> <up99ph$l7gv$1@dont-email.me>
<upajva$uvcc$1@raubtier-asyl.eternal-september.org>
<upc058$16gik$1@dont-email.me>
<updpvf$1j50l$1@raubtier-asyl.eternal-september.org>
<upeao1$1m29s$1@dont-email.me>
<upfr60$2114k$1@raubtier-asyl.eternal-september.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Injection-Date: Thu, 1 Feb 2024 20:05:29 -0000 (UTC)
Injection-Info: dont-email.me; posting-host="e5db24bf58349e0f24b4ca76196085dd";
logging-data="2335597"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX19niHXWvneUJrC/7ZqZVVd0b8iMOLIq49c="
User-Agent: Mozilla Thunderbird
Cancel-Lock: sha1:Fh3RBd73wxp64P29jTUStq8zu+w=
Content-Language: en-US
In-Reply-To: <upfr60$2114k$1@raubtier-asyl.eternal-september.org>
 by: Chris M. Thomasson - Thu, 1 Feb 2024 20:05 UTC

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

Re: The ultimate thread pool

<upguk4$27efr$1@redfloyd.dont-email.me>

  copy mid

https://www.novabbs.com/devel/article-flat.php?id=3108&group=comp.lang.c%2B%2B#3108

  copy link   Newsgroups: comp.lang.c++
Path: i2pn2.org!i2pn.org!news.chmurka.net!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!redfloyd.dont-email.me!.POSTED!not-for-mail
From: no.spam....@its.invalid (red floyd)
Newsgroups: comp.lang.c++
Subject: Re: The ultimate thread pool
Date: Thu, 1 Feb 2024 12:23:31 -0800
Organization: A noiseless patient Spider
Lines: 36
Message-ID: <upguk4$27efr$1@redfloyd.dont-email.me>
References: <uou5ir$2cuko$2@raubtier-asyl.eternal-september.org>
<up3r6t$3hjng$1@dont-email.me> <up99ph$l7gv$1@dont-email.me>
<upajva$uvcc$1@raubtier-asyl.eternal-september.org>
<upc058$16gik$1@dont-email.me>
<updpvf$1j50l$1@raubtier-asyl.eternal-september.org>
<upeao1$1m29s$1@dont-email.me>
<upfr60$2114k$1@raubtier-asyl.eternal-september.org>
<upgti9$278rd$1@dont-email.me>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Date: Thu, 1 Feb 2024 20:23:32 -0000 (UTC)
Injection-Info: redfloyd.dont-email.me; posting-host="a135db5af8baedda1757df51199f794c";
logging-data="2341371"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX18Gfa5ZG5wWIZak8qjZWJlYmOAUMp3+iCQ="
User-Agent: Mozilla Thunderbird
Cancel-Lock: sha1:V2c37v7kJ25h6lkjxOK7WV1LQOA=
Content-Language: en-US
In-Reply-To: <upgti9$278rd$1@dont-email.me>
 by: red floyd - Thu, 1 Feb 2024 20:23 UTC

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]

Re: The ultimate thread pool

<upgv1p$278rc$1@dont-email.me>

  copy mid

https://www.novabbs.com/devel/article-flat.php?id=3109&group=comp.lang.c%2B%2B#3109

  copy link   Newsgroups: comp.lang.c++
Path: i2pn2.org!i2pn.org!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail
From: chris.m....@gmail.com (Chris M. Thomasson)
Newsgroups: comp.lang.c++
Subject: Re: The ultimate thread pool
Date: Thu, 1 Feb 2024 12:30:49 -0800
Organization: A noiseless patient Spider
Lines: 44
Message-ID: <upgv1p$278rc$1@dont-email.me>
References: <uou5ir$2cuko$2@raubtier-asyl.eternal-september.org>
<up3r6t$3hjng$1@dont-email.me> <up99ph$l7gv$1@dont-email.me>
<upajva$uvcc$1@raubtier-asyl.eternal-september.org>
<upc058$16gik$1@dont-email.me>
<updpvf$1j50l$1@raubtier-asyl.eternal-september.org>
<upeao1$1m29s$1@dont-email.me>
<upfr60$2114k$1@raubtier-asyl.eternal-september.org>
<upgti9$278rd$1@dont-email.me> <upguk4$27efr$1@redfloyd.dont-email.me>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Date: Thu, 1 Feb 2024 20:30:49 -0000 (UTC)
Injection-Info: dont-email.me; posting-host="e5db24bf58349e0f24b4ca76196085dd";
logging-data="2335596"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX191QSV44V4VKSAQtgTE0IF3XgRa8fTk2I4="
User-Agent: Mozilla Thunderbird
Cancel-Lock: sha1:fH7HirH+mTpp2vCYJvoLFtHRh5c=
In-Reply-To: <upguk4$27efr$1@redfloyd.dont-email.me>
Content-Language: en-US
 by: Chris M. Thomasson - Thu, 1 Feb 2024 20:30 UTC

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.

Re: The ultimate thread pool

<upm2nq$38f0a$1@raubtier-asyl.eternal-september.org>

  copy mid

https://www.novabbs.com/devel/article-flat.php?id=3112&group=comp.lang.c%2B%2B#3112

  copy link   Newsgroups: comp.lang.c++
Path: i2pn2.org!rocksolid2!news.neodome.net!news.mixmin.net!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!raubtier-asyl.eternal-september.org!.POSTED!not-for-mail
From: Bonita.M...@gmail.com (Bonita Montero)
Newsgroups: comp.lang.c++
Subject: Re: The ultimate thread pool
Date: Sat, 3 Feb 2024 20:04:29 +0100
Organization: A noiseless patient Spider
Lines: 26
Message-ID: <upm2nq$38f0a$1@raubtier-asyl.eternal-september.org>
References: <uou5ir$2cuko$2@raubtier-asyl.eternal-september.org>
<up3r6t$3hjng$1@dont-email.me> <up99ph$l7gv$1@dont-email.me>
<upajva$uvcc$1@raubtier-asyl.eternal-september.org>
<upc058$16gik$1@dont-email.me>
<updpvf$1j50l$1@raubtier-asyl.eternal-september.org>
<upeao1$1m29s$1@dont-email.me>
<upfr60$2114k$1@raubtier-asyl.eternal-september.org>
<upgti9$278rd$1@dont-email.me>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Date: Sat, 3 Feb 2024 19:04:26 -0000 (UTC)
Injection-Info: raubtier-asyl.eternal-september.org; posting-host="cddeb62b6883bf93385b7b11e195fc6f";
logging-data="3423242"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX19Ubp/5rWvcZrdO5H0116Mg/c7KlaEOMdI="
User-Agent: Mozilla Thunderbird
Cancel-Lock: sha1:rlngGGyDGAj+wToIry73Ax2ArUc=
In-Reply-To: <upgti9$278rd$1@dont-email.me>
Content-Language: de-DE
 by: Bonita Montero - Sat, 3 Feb 2024 19:04 UTC

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.

Re: The ultimate thread pool

<upm6a8$3943l$1@dont-email.me>

  copy mid

https://www.novabbs.com/devel/article-flat.php?id=3113&group=comp.lang.c%2B%2B#3113

  copy link   Newsgroups: comp.lang.c++
Path: i2pn2.org!i2pn.org!news.nntp4.net!news.hispagatos.org!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail
From: chris.m....@gmail.com (Chris M. Thomasson)
Newsgroups: comp.lang.c++
Subject: Re: The ultimate thread pool
Date: Sat, 3 Feb 2024 12:05:29 -0800
Organization: A noiseless patient Spider
Lines: 31
Message-ID: <upm6a8$3943l$1@dont-email.me>
References: <uou5ir$2cuko$2@raubtier-asyl.eternal-september.org>
<up3r6t$3hjng$1@dont-email.me> <up99ph$l7gv$1@dont-email.me>
<upajva$uvcc$1@raubtier-asyl.eternal-september.org>
<upc058$16gik$1@dont-email.me>
<updpvf$1j50l$1@raubtier-asyl.eternal-september.org>
<upeao1$1m29s$1@dont-email.me>
<upfr60$2114k$1@raubtier-asyl.eternal-september.org>
<upgti9$278rd$1@dont-email.me>
<upm2nq$38f0a$1@raubtier-asyl.eternal-september.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Date: Sat, 3 Feb 2024 20:05:29 -0000 (UTC)
Injection-Info: dont-email.me; posting-host="701cdbc117df9d402df8754b470a5d48";
logging-data="3444853"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX19kICUOKQPSrAuPgdOvBxz3BYKL1c+EOQM="
User-Agent: Mozilla Thunderbird
Cancel-Lock: sha1:7lsnXa4TH0A1MyaC6wukSgj8pTg=
Content-Language: en-US
In-Reply-To: <upm2nq$38f0a$1@raubtier-asyl.eternal-september.org>
 by: Chris M. Thomasson - Sat, 3 Feb 2024 20:05 UTC

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.

Re: The ultimate thread pool

<upn5gs$3harq$1@raubtier-asyl.eternal-september.org>

  copy mid

https://www.novabbs.com/devel/article-flat.php?id=3115&group=comp.lang.c%2B%2B#3115

  copy link   Newsgroups: comp.lang.c++
Path: i2pn2.org!i2pn.org!news.hispagatos.org!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!raubtier-asyl.eternal-september.org!.POSTED!not-for-mail
From: Bonita.M...@gmail.com (Bonita Montero)
Newsgroups: comp.lang.c++
Subject: Re: The ultimate thread pool
Date: Sun, 4 Feb 2024 05:58:04 +0100
Organization: A noiseless patient Spider
Lines: 9
Message-ID: <upn5gs$3harq$1@raubtier-asyl.eternal-september.org>
References: <uou5ir$2cuko$2@raubtier-asyl.eternal-september.org>
<up3r6t$3hjng$1@dont-email.me> <up99ph$l7gv$1@dont-email.me>
<upajva$uvcc$1@raubtier-asyl.eternal-september.org>
<upc058$16gik$1@dont-email.me>
<updpvf$1j50l$1@raubtier-asyl.eternal-september.org>
<upeao1$1m29s$1@dont-email.me>
<upfr60$2114k$1@raubtier-asyl.eternal-september.org>
<upgti9$278rd$1@dont-email.me>
<upm2nq$38f0a$1@raubtier-asyl.eternal-september.org>
<upm6a8$3943l$1@dont-email.me>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Injection-Date: Sun, 4 Feb 2024 04:58:04 -0000 (UTC)
Injection-Info: raubtier-asyl.eternal-september.org; posting-host="314d3c68bae0be530334a98cc7131d1b";
logging-data="3713914"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1/xQYZs53G2w4cYTUJGw0T51+MiWEzJsPM="
User-Agent: Mozilla Thunderbird
Cancel-Lock: sha1:M6w3XKKJJDI8Fw81PV50a91CO9w=
In-Reply-To: <upm6a8$3943l$1@dont-email.me>
Content-Language: de-DE
 by: Bonita Montero - Sun, 4 Feb 2024 04:58 UTC

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.

Re: The ultimate thread pool

<upn7eb$3hi85$1@dont-email.me>

  copy mid

https://www.novabbs.com/devel/article-flat.php?id=3116&group=comp.lang.c%2B%2B#3116

  copy link   Newsgroups: comp.lang.c++
Path: i2pn2.org!i2pn.org!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail
From: chris.m....@gmail.com (Chris M. Thomasson)
Newsgroups: comp.lang.c++
Subject: Re: The ultimate thread pool
Date: Sat, 3 Feb 2024 21:30:51 -0800
Organization: A noiseless patient Spider
Lines: 12
Message-ID: <upn7eb$3hi85$1@dont-email.me>
References: <uou5ir$2cuko$2@raubtier-asyl.eternal-september.org>
<up3r6t$3hjng$1@dont-email.me> <up99ph$l7gv$1@dont-email.me>
<upajva$uvcc$1@raubtier-asyl.eternal-september.org>
<upc058$16gik$1@dont-email.me>
<updpvf$1j50l$1@raubtier-asyl.eternal-september.org>
<upeao1$1m29s$1@dont-email.me>
<upfr60$2114k$1@raubtier-asyl.eternal-september.org>
<upgti9$278rd$1@dont-email.me>
<upm2nq$38f0a$1@raubtier-asyl.eternal-september.org>
<upm6a8$3943l$1@dont-email.me>
<upn5gs$3harq$1@raubtier-asyl.eternal-september.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Injection-Date: Sun, 4 Feb 2024 05:30:51 -0000 (UTC)
Injection-Info: dont-email.me; posting-host="d3cc8c0b731b0b00102a0ce70e10bacb";
logging-data="3721477"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1/FQUSjG9x/V3pk6LiGfCmpebiaYHGxsdk="
User-Agent: Mozilla Thunderbird
Cancel-Lock: sha1:OB08U8QbIV8H/ABM+LcerhrkS8c=
Content-Language: en-US
In-Reply-To: <upn5gs$3harq$1@raubtier-asyl.eternal-september.org>
 by: Chris M. Thomasson - Sun, 4 Feb 2024 05:30 UTC

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?

Re: The ultimate thread pool

<upnbje$3i3mu$1@raubtier-asyl.eternal-september.org>

  copy mid

https://www.novabbs.com/devel/article-flat.php?id=3117&group=comp.lang.c%2B%2B#3117

  copy link   Newsgroups: comp.lang.c++
Path: i2pn2.org!i2pn.org!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!raubtier-asyl.eternal-september.org!.POSTED!not-for-mail
From: Bonita.M...@gmail.com (Bonita Montero)
Newsgroups: comp.lang.c++
Subject: Re: The ultimate thread pool
Date: Sun, 4 Feb 2024 07:41:51 +0100
Organization: A noiseless patient Spider
Lines: 16
Message-ID: <upnbje$3i3mu$1@raubtier-asyl.eternal-september.org>
References: <uou5ir$2cuko$2@raubtier-asyl.eternal-september.org>
<up3r6t$3hjng$1@dont-email.me> <up99ph$l7gv$1@dont-email.me>
<upajva$uvcc$1@raubtier-asyl.eternal-september.org>
<upc058$16gik$1@dont-email.me>
<updpvf$1j50l$1@raubtier-asyl.eternal-september.org>
<upeao1$1m29s$1@dont-email.me>
<upfr60$2114k$1@raubtier-asyl.eternal-september.org>
<upgti9$278rd$1@dont-email.me>
<upm2nq$38f0a$1@raubtier-asyl.eternal-september.org>
<upm6a8$3943l$1@dont-email.me>
<upn5gs$3harq$1@raubtier-asyl.eternal-september.org>
<upn7eb$3hi85$1@dont-email.me>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Injection-Date: Sun, 4 Feb 2024 06:41:50 -0000 (UTC)
Injection-Info: raubtier-asyl.eternal-september.org; posting-host="314d3c68bae0be530334a98cc7131d1b";
logging-data="3739358"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1/ABvCJziD6nov5CCn0bKFiEnhCC89fGGM="
User-Agent: Mozilla Thunderbird
Cancel-Lock: sha1:Gmcex94czQofbovYkY1PhZfKTp0=
Content-Language: de-DE
In-Reply-To: <upn7eb$3hi85$1@dont-email.me>
 by: Bonita Montero - Sun, 4 Feb 2024 06:41 UTC

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.


devel / comp.lang.c++ / The ultimate thread pool

Pages:12
server_pubkey.txt

rocksolid light 0.9.81
clearnet tor