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

?

--- MBSE BBS v1.0.8.4 (Linux-x86_64)
* Origin: A noiseless patient Spider (3:633/280.2@fidonet)

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.

--- MBSE BBS v1.0.8.4 (Linux-x86_64)
* Origin: A noiseless patient Spider (3:633/280.2@fidonet)

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

--- MBSE BBS v1.0.8.4 (Linux-x86_64)
* Origin: A noiseless patient Spider (3:633/280.2@fidonet)

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.



--- MBSE BBS v1.0.8.4 (Linux-x86_64)
* Origin: A noiseless patient Spider (3:633/280.2@fidonet)

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?


--- MBSE BBS v1.0.8.4 (Linux-x86_64)
* Origin: A noiseless patient Spider (3:633/280.2@fidonet)

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

--- MBSE BBS v1.0.8.4 (Linux-x86_64)
* Origin: A noiseless patient Spider (3:633/280.2@fidonet)

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

--- MBSE BBS v1.0.8.4 (Linux-x86_64)
* Origin: A noiseless patient Spider (3:633/280.2@fidonet)

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.



--- MBSE BBS v1.0.8.4 (Linux-x86_64)
* Origin: A noiseless patient Spider (3:633/280.2@fidonet)

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

--- MBSE BBS v1.0.8.4 (Linux-x86_64)
* Origin: A noiseless patient Spider (3:633/280.2@fidonet)

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]


--- MBSE BBS v1.0.8.4 (Linux-x86_64)
* Origin: A noiseless patient Spider (3:633/280.2@fidonet)

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.



--- MBSE BBS v1.0.8.4 (Linux-x86_64)
* Origin: A noiseless patient Spider (3:633/280.2@fidonet)

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.


--- MBSE BBS v1.0.8.4 (Linux-x86_64)
* Origin: A noiseless patient Spider (3:633/280.2@fidonet)

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.

--- MBSE BBS v1.0.8.4 (Linux-x86_64)
* Origin: A noiseless patient Spider (3:633/280.2@fidonet)

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.


--- MBSE BBS v1.0.8.4 (Linux-x86_64)
* Origin: A noiseless patient Spider (3:633/280.2@fidonet)

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?

--- MBSE BBS v1.0.8.4 (Linux-x86_64)
* Origin: A noiseless patient Spider (3:633/280.2@fidonet)

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.

--- MBSE BBS v1.0.8.4 (Linux-x86_64)
* Origin: A noiseless patient Spider (3:633/280.2@fidonet)

On 2/3/2024 10:41 PM, Bonita Montero wrote:

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.

Why are they incorrect, according to you? Boil it down to a simple
example where these warnings are incorrect. That way I can reproduce it
on my side.

--- MBSE BBS v1.0.8.4 (Linux-x86_64)
* Origin: A noiseless patient Spider (3:633/280.2@fidonet)

On 2/3/2024 10:41 PM, Bonita Montero wrote:

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.

https://youtu.be/hAMQIvEtcJM

--- MBSE BBS v1.0.8.4 (Linux-x86_64)
* Origin: A noiseless patient Spider (3:633/280.2@fidonet)

Am 04.02.2024 um 22:59 schrieb Chris M. Thomasson:

Why are they incorrect, according to you? ...

No, according to what they should warn for.


--- MBSE BBS v1.0.8.4 (Linux-x86_64)
* Origin: A noiseless patient Spider (3:633/280.2@fidonet)

On 2/5/2024 12:01 AM, Bonita Montero wrote:

Am 04.02.2024 um 22:59 schrieb Chris M. Thomasson:

Why are they incorrect, according to you? ...

No, according to what they should warn for.

Can you create a little self-contained example that shows these warnings?

--- MBSE BBS v1.0.8.4 (Linux-x86_64)
* Origin: A noiseless patient Spider (3:633/280.2@fidonet)

Am 05.02.2024 um 20:09 schrieb Chris M. Thomasson:

Can you create a little self-contained example that shows these warnings?

Make the pragmas commented and look what the IDE shows as warnings.


--- MBSE BBS v1.0.8.4 (Linux-x86_64)
* Origin: A noiseless patient Spider (3:633/280.2@fidonet)

On 2/5/2024 10:12 PM, Bonita Montero wrote:

Am 05.02.2024 um 20:09 schrieb Chris M. Thomasson:

Can you create a little self-contained example that shows these warnings?

Make the pragmas commented and look what the IDE shows as warnings.

What is in:
______________________
#include <cassert>
#include "thread_pool.h"
#include "invoke_on_destruct.h"
______________________

?

--- MBSE BBS v1.0.8.4 (Linux-x86_64)
* Origin: A noiseless patient Spider (3:633/280.2@fidonet)

On 2/5/2024 10:34 PM, Chris M. Thomasson wrote:

On 2/5/2024 10:12 PM, Bonita Montero wrote:

Am 05.02.2024 um 20:09 schrieb Chris M. Thomasson:

Can you create a little self-contained example that shows these
warnings?

Make the pragmas commented and look what the IDE shows as warnings.

What is in:
______________________
#include <cassert>
#include "thread_pool.h"
#include "invoke_on_destruct.h"
______________________

?

You have some issues here. These warnings are not for kicks and giggles,
so to speak. If these warnings are wrong, you need to file a bug report
to the MSVC team.

--- MBSE BBS v1.0.8.4 (Linux-x86_64)
* Origin: A noiseless patient Spider (3:633/280.2@fidonet)

On 2/5/2024 10:12 PM, Bonita Montero wrote:

Am 05.02.2024 um 20:09 schrieb Chris M. Thomasson:

Can you create a little self-contained example that shows these warnings?

Make the pragmas commented and look what the IDE shows as warnings.

Think about getting a warning free compile. Think about what these
warnings actually mean. If you find a bug, report it to the MSVC team.

--- MBSE BBS v1.0.8.4 (Linux-x86_64)
* Origin: A noiseless patient Spider (3:633/280.2@fidonet)

On 2/5/2024 10:34 PM, Chris M. Thomasson wrote:

On 2/5/2024 10:12 PM, Bonita Montero wrote:

Am 05.02.2024 um 20:09 schrieb Chris M. Thomasson:

Can you create a little self-contained example that shows these
warnings?

Make the pragmas commented and look what the IDE shows as warnings.

What is in:
______________________
#include <cassert>
#include "thread_pool.h"

#include "invoke_on_destruct.h"

^^^^^^^^^^^^^^^^^^^^^^

What is that for?

______________________

?

--- MBSE BBS v1.0.8.4 (Linux-x86_64)
* Origin: A noiseless patient Spider (3:633/280.2@fidonet)

Am 06.02.2024 um 07:34 schrieb Chris M. Thomasson:

On 2/5/2024 10:12 PM, Bonita Montero wrote:

Am 05.02.2024 um 20:09 schrieb Chris M. Thomasson:

Can you create a little self-contained example that shows these
warnings?

Make the pragmas commented and look what the IDE shows as warnings.

What is in:
______________________
#include <cassert>
#include "thread_pool.h"

The header I posted.

#include "invoke_on_destruct.h"

Sth. like experimental::scope_exit, this is my code:

#pragma once
#include <utility>

template<typename Fn>
requires requires( Fn fn ) { { fn() }; }
struct invoke_on_destruct
{
private:
Fn m_fn;
bool m_enabled;
public:
invoke_on_destruct( Fn &&fn ) :
m_fn( std::forward<Fn>( fn ) ),
m_enabled( true )
{
}
~invoke_on_destruct()
{
if( m_enabled )
m_fn();
}
void operator ()()
{
if( m_enabled )
m_enabled = false,
m_fn();
}
void disable()
{
m_enabled = false;
}
invoke_on_destruct &enable()
{
m_enabled = true;
return *this;
}
};


--- MBSE BBS v1.0.8.4 (Linux-x86_64)
* Origin: A noiseless patient Spider (3:633/280.2@fidonet)

Am 06.02.2024 um 07:38 schrieb Chris M. Thomasson:

Think about getting a warning free compile. Think about what these
warnings actually mean. If you find a bug, report it to the MSVC team.

Where the compiler warns me there are no errors,
these are false warnings.

--- MBSE BBS v1.0.8.4 (Linux-x86_64)
* Origin: A noiseless patient Spider (3:633/280.2@fidonet)

Am 06.02.2024 um 07:38 schrieb Chris M. Thomasson:

On 2/5/2024 10:12 PM, Bonita Montero wrote:

Am 05.02.2024 um 20:09 schrieb Chris M. Thomasson:

Can you create a little self-contained example that shows these
warnings?

Make the pragmas commented and look what the IDE shows as warnings.

Think about getting a warning free compile. Think about what these
warnings actually mean. If you find a bug, report it to the MSVC team.

Try this ...

void fn( unique_lock<mutex> &lock )
{
assert(lock);
lock.unlock();
}

.... and you'll get a warning.


--- MBSE BBS v1.0.8.4 (Linux-x86_64)
* Origin: A noiseless patient Spider (3:633/280.2@fidonet)

On 2/6/2024 2:17 AM, Bonita Montero wrote:

Am 06.02.2024 um 07:38 schrieb Chris M. Thomasson:

Think about getting a warning free compile. Think about what these
warnings actually mean. If you find a bug, report it to the MSVC team.

Where the compiler warns me there are no errors,
these are false warnings.

Well, that deserves a bug report?

--- MBSE BBS v1.0.8.4 (Linux-x86_64)
* Origin: A noiseless patient Spider (3:633/280.2@fidonet)

On 2/6/2024 5:01 AM, Bonita Montero wrote:

Am 06.02.2024 um 07:38 schrieb Chris M. Thomasson:

On 2/5/2024 10:12 PM, Bonita Montero wrote:

Am 05.02.2024 um 20:09 schrieb Chris M. Thomasson:

Can you create a little self-contained example that shows these
warnings?

Make the pragmas commented and look what the IDE shows as warnings.

Think about getting a warning free compile. Think about what these
warnings actually mean. If you find a bug, report it to the MSVC team.

Try this ...

void fn( unique_lock<mutex> &lock )
{
ÿÿÿÿassert(lock);
ÿÿÿÿlock.unlock();
}

... and you'll get a warning.

Fwiw, I get no warning with:

{
std::unique_lock<std::mutex> lock(m_mutex);
assert(lock);
lock.unlock();
//lock.unlock(); // this throws an exception.
}

The interesting part is the code for std::unique_lock:

~unique_lock() noexcept {
if (_Owns) {
_Pmtx->unlock();
}
}


I was wondering why std::unique_lock did not try to unlock it twice in
the dtor. Well, the code for std::~unique_lock that MSVC is using
answers my question. Its that _Owns variable. Humm...

--- MBSE BBS v1.0.8.4 (Linux-x86_64)
* Origin: A noiseless patient Spider (3:633/280.2@fidonet)

Am 06.02.2024 um 20:55 schrieb Chris M. Thomasson:

On 2/6/2024 2:17 AM, Bonita Montero wrote:

Am 06.02.2024 um 07:38 schrieb Chris M. Thomasson:

Think about getting a warning free compile. Think about what these
warnings actually mean. If you find a bug, report it to the MSVC team.

Where the compiler warns me there are no errors,
these are false warnings.

Well, that deserves a bug report?

I won't file it.


--- MBSE BBS v1.0.8.4 (Linux-x86_64)
* Origin: A noiseless patient Spider (3:633/280.2@fidonet)

Am 06.02.2024 um 21:07 schrieb Chris M. Thomasson:

On 2/6/2024 5:01 AM, Bonita Montero wrote:

Am 06.02.2024 um 07:38 schrieb Chris M. Thomasson:

On 2/5/2024 10:12 PM, Bonita Montero wrote:

Am 05.02.2024 um 20:09 schrieb Chris M. Thomasson:

Can you create a little self-contained example that shows these
warnings?

Make the pragmas commented and look what the IDE shows as warnings.

Think about getting a warning free compile. Think about what these
warnings actually mean. If you find a bug, report it to the MSVC team.

Try this ...

void fn( unique_lock<mutex> &lock )
{
ÿÿÿÿÿassert(lock);
ÿÿÿÿÿlock.unlock();
}

... and you'll get a warning.

Fwiw, I get no warning with:

{
ÿÿÿ std::unique_lock<std::mutex> lock(m_mutex);
ÿÿÿ assert(lock);
ÿÿÿ lock.unlock();
ÿÿÿ //lock.unlock(); // this throws an exception.
}

That's sth. totally different. My function has the pre-condition
that it inherits the lock of the calling function and sometimes
it unlocks it.

The interesting part is the code for std::unique_lock:

~unique_lock() noexcept {
ÿÿÿ if (_Owns) {
ÿÿÿÿÿÿÿ _Pmtx->unlock();
ÿÿÿ }
}

I was wondering why std::unique_lock did not try to unlock it twice in
the dtor. Well, the code for std::~unique_lock that MSVC is using
answers my question. Its that _Owns variable. Humm...

--- MBSE BBS v1.0.8.4 (Linux-x86_64)
* Origin: A noiseless patient Spider (3:633/280.2@fidonet)

On 2/7/2024 8:15 AM, Bonita Montero wrote:

Am 06.02.2024 um 21:07 schrieb Chris M. Thomasson:

On 2/6/2024 5:01 AM, Bonita Montero wrote:

Am 06.02.2024 um 07:38 schrieb Chris M. Thomasson:

On 2/5/2024 10:12 PM, Bonita Montero wrote:

Am 05.02.2024 um 20:09 schrieb Chris M. Thomasson:

Can you create a little self-contained example that shows these
warnings?

Make the pragmas commented and look what the IDE shows as warnings.

Think about getting a warning free compile. Think about what these
warnings actually mean. If you find a bug, report it to the MSVC team.

Try this ...

void fn( unique_lock<mutex> &lock )
{
ÿÿÿÿÿassert(lock);
ÿÿÿÿÿlock.unlock();
}

... and you'll get a warning.

Fwiw, I get no warning with:

{
ÿÿÿÿ std::unique_lock<std::mutex> lock(m_mutex);
ÿÿÿÿ assert(lock);
ÿÿÿÿ lock.unlock();
ÿÿÿÿ //lock.unlock(); // this throws an exception.
}

That's sth. totally different. My function has the pre-condition
that it inherits the lock of the calling function and sometimes
it unlocks it.

Ahhh. I got them with:
__________________________________
namespace ct
{
struct mutex_test
{
std::mutex m_mutex;

void
bar(std::unique_lock<std::mutex>& lock)
{
assert(lock); // better be locked!
lock.unlock();
}

void
foo()
{
std::unique_lock<std::mutex> lock(m_mutex);
bar(lock); // beware. unlocks the damn thing!
lock.lock(); // okay...
}
};
}
__________________________________

Give the warnings:
__________________________________
Severity Code Description Project File Line Suppression State Details
Warning C26115 Failing to release lock 'this->m_mutex' in function 'ct::mutex_test::foo'. ct_threads D:\ct_dev\projects\ct_threads\ct_threads\ct_main.cpp 26

Warning C26111 Caller failing to release lock 'this->m_mutex' before
calling function 'std::unique_lock<std::mutex>::lock'. ct_threads D:\ct_dev\projects\ct_threads\ct_threads\ct_main.cpp 26

Warning C26110 Caller failing to hold lock 'lock' before calling
function 'std::unique_lock<std::mutex>::unlock'. ct_threads D:\ct_dev\projects\ct_threads\ct_threads\ct_main.cpp 18 __________________________________


You just have to be very careful with this type of logic. These warnings
elude to that.



[...]

--- MBSE BBS v1.0.8.4 (Linux-x86_64)
* Origin: A noiseless patient Spider (3:633/280.2@fidonet)

On 2/7/2024 8:13 AM, Bonita Montero wrote:

Am 06.02.2024 um 20:55 schrieb Chris M. Thomasson:

On 2/6/2024 2:17 AM, Bonita Montero wrote:

Am 06.02.2024 um 07:38 schrieb Chris M. Thomasson:

Think about getting a warning free compile. Think about what these
warnings actually mean. If you find a bug, report it to the MSVC team.

Where the compiler warns me there are no errors,
these are false warnings.

Well, that deserves a bug report?

I won't file it.

Maybe you should. However, the warnings do flag some "sketchy" things
are going on.

--- MBSE BBS v1.0.8.4 (Linux-x86_64)
* Origin: A noiseless patient Spider (3:633/280.2@fidonet)

Am 07.02.2024 um 21:38 schrieb Chris M. Thomasson:

On 2/7/2024 8:15 AM, Bonita Montero wrote:

Am 06.02.2024 um 21:07 schrieb Chris M. Thomasson:

On 2/6/2024 5:01 AM, Bonita Montero wrote:

Am 06.02.2024 um 07:38 schrieb Chris M. Thomasson:

On 2/5/2024 10:12 PM, Bonita Montero wrote:

Am 05.02.2024 um 20:09 schrieb Chris M. Thomasson:

Can you create a little self-contained example that shows these >>>>>>> warnings?

Make the pragmas commented and look what the IDE shows as warnings. >>>>>>

Think about getting a warning free compile. Think about what these
warnings actually mean. If you find a bug, report it to the MSVC team. >>>>

Try this ...

void fn( unique_lock<mutex> &lock )
{
ÿÿÿÿÿassert(lock);
ÿÿÿÿÿlock.unlock();
}

... and you'll get a warning.

Fwiw, I get no warning with:

{
ÿÿÿÿ std::unique_lock<std::mutex> lock(m_mutex);
ÿÿÿÿ assert(lock);
ÿÿÿÿ lock.unlock();
ÿÿÿÿ //lock.unlock(); // this throws an exception.
}

That's sth. totally different. My function has the pre-condition
that it inherits the lock of the calling function and sometimes
it unlocks it.

Ahhh. I got them with:
__________________________________
namespace ct
{
ÿÿÿ struct mutex_test
ÿÿÿ {
ÿÿÿÿÿÿÿ std::mutex m_mutex;

ÿÿÿÿÿÿÿ void
ÿÿÿÿÿÿÿ bar(std::unique_lock<std::mutex>& lock)
ÿÿÿÿÿÿÿ {
ÿÿÿÿÿÿÿÿÿÿÿ assert(lock); // better be locked!
ÿÿÿÿÿÿÿÿÿÿÿ lock.unlock();
ÿÿÿÿÿÿÿ }

ÿÿÿÿÿÿÿ void
ÿÿÿÿÿÿÿ foo()
ÿÿÿÿÿÿÿ {
ÿÿÿÿÿÿÿÿÿÿÿ std::unique_lock<std::mutex> lock(m_mutex);
ÿÿÿÿÿÿÿÿÿÿÿ bar(lock); // beware. unlocks the damn thing!
ÿÿÿÿÿÿÿÿÿÿÿ lock.lock(); // okay...
ÿÿÿÿÿÿÿ }
ÿÿÿ };
}
__________________________________

Give the warnings:
__________________________________
Severityÿÿÿ Codeÿÿÿ Descriptionÿÿÿ Projectÿÿÿ Fileÿÿÿ Line
Suppression Stateÿÿÿ Details
Warningÿÿÿ C26115ÿÿÿ Failing to release lock 'this->m_mutex' in function 'ct::mutex_test::foo'.ÿÿÿ ct_threads D:\ct_dev\projects\ct_threads\ct_threads\ct_main.cppÿÿÿ 26

Warningÿÿÿ C26111ÿÿÿ Caller failing to release lock 'this->m_mutex'
before calling function 'std::unique_lock<std::mutex>::lock'.
ct_threads D:\ct_dev\projects\ct_threads\ct_threads\ct_main.cppÿÿÿ 26

Warningÿÿÿ C26110ÿÿÿ Caller failing to hold lock 'lock' before calling function 'std::unique_lock<std::mutex>::unlock'.ÿÿÿ ct_threads D:\ct_dev\projects\ct_threads\ct_threads\ct_main.cppÿÿÿ 18 __________________________________

You just have to be very careful with this type of logic. These warnings elude to that.

Can't you read my code ?
That's still sth. completely different than what I did.


--- MBSE BBS v1.0.8.4 (Linux-x86_64)
* Origin: A noiseless patient Spider (3:633/280.2@fidonet)

On 2/8/2024 4:07 AM, Bonita Montero wrote:

Am 07.02.2024 um 21:38 schrieb Chris M. Thomasson:

On 2/7/2024 8:15 AM, Bonita Montero wrote:

Am 06.02.2024 um 21:07 schrieb Chris M. Thomasson:

On 2/6/2024 5:01 AM, Bonita Montero wrote:

Am 06.02.2024 um 07:38 schrieb Chris M. Thomasson:

On 2/5/2024 10:12 PM, Bonita Montero wrote:

Am 05.02.2024 um 20:09 schrieb Chris M. Thomasson:

Can you create a little self-contained example that shows these >>>>>>>> warnings?

Make the pragmas commented and look what the IDE shows as warnings. >>>>>>>

Think about getting a warning free compile. Think about what these >>>>>> warnings actually mean. If you find a bug, report it to the MSVC
team.

Try this ...

void fn( unique_lock<mutex> &lock )
{
ÿÿÿÿÿassert(lock);
ÿÿÿÿÿlock.unlock();
}

... and you'll get a warning.

Fwiw, I get no warning with:

{
ÿÿÿÿ std::unique_lock<std::mutex> lock(m_mutex);
ÿÿÿÿ assert(lock);
ÿÿÿÿ lock.unlock();
ÿÿÿÿ //lock.unlock(); // this throws an exception.
}

That's sth. totally different. My function has the pre-condition
that it inherits the lock of the calling function and sometimes
it unlocks it.

Ahhh. I got them with:
__________________________________
namespace ct
{
ÿÿÿÿ struct mutex_test
ÿÿÿÿ {
ÿÿÿÿÿÿÿÿ std::mutex m_mutex;

ÿÿÿÿÿÿÿÿ void
ÿÿÿÿÿÿÿÿ bar(std::unique_lock<std::mutex>& lock)
ÿÿÿÿÿÿÿÿ {
ÿÿÿÿÿÿÿÿÿÿÿÿ assert(lock); // better be locked!
ÿÿÿÿÿÿÿÿÿÿÿÿ lock.unlock();
ÿÿÿÿÿÿÿÿ }

ÿÿÿÿÿÿÿÿ void
ÿÿÿÿÿÿÿÿ foo()
ÿÿÿÿÿÿÿÿ {
ÿÿÿÿÿÿÿÿÿÿÿÿ std::unique_lock<std::mutex> lock(m_mutex);
ÿÿÿÿÿÿÿÿÿÿÿÿ bar(lock); // beware. unlocks the damn thing!
ÿÿÿÿÿÿÿÿÿÿÿÿ lock.lock(); // okay...
ÿÿÿÿÿÿÿÿ }
ÿÿÿÿ };
}
__________________________________

Give the warnings:
__________________________________
Severityÿÿÿ Codeÿÿÿ Descriptionÿÿÿ Projectÿÿÿ Fileÿÿÿ Line Suppression
Stateÿÿÿ Details
Warningÿÿÿ C26115ÿÿÿ Failing to release lock 'this->m_mutex' in
function 'ct::mutex_test::foo'.ÿÿÿ ct_threads
D:\ct_dev\projects\ct_threads\ct_threads\ct_main.cppÿÿÿ 26

Warningÿÿÿ C26111ÿÿÿ Caller failing to release lock 'this->m_mutex'
before calling function 'std::unique_lock<std::mutex>::lock'.
ct_threads D:\ct_dev\projects\ct_threads\ct_threads\ct_main.cppÿÿÿ 26

Warningÿÿÿ C26110ÿÿÿ Caller failing to hold lock 'lock' before calling
function 'std::unique_lock<std::mutex>::unlock'.ÿÿÿ ct_threads
D:\ct_dev\projects\ct_threads\ct_threads\ct_main.cppÿÿÿ 18
__________________________________


You just have to be very careful with this type of logic. These
warnings elude to that.

Can't you read my code ?

Yes.

That's still sth. completely different than what I did.

I just wanted to get MSVC to pop out those "false" warnings. Mission accomplished.

--- MBSE BBS v1.0.8.4 (Linux-x86_64)
* Origin: A noiseless patient Spider (3:633/280.2@fidonet)

On 2/8/2024 4:07 AM, Bonita Montero wrote:

Am 07.02.2024 um 21:38 schrieb Chris M. Thomasson:

On 2/7/2024 8:15 AM, Bonita Montero wrote:

Am 06.02.2024 um 21:07 schrieb Chris M. Thomasson:

On 2/6/2024 5:01 AM, Bonita Montero wrote:

Am 06.02.2024 um 07:38 schrieb Chris M. Thomasson:

On 2/5/2024 10:12 PM, Bonita Montero wrote:

Am 05.02.2024 um 20:09 schrieb Chris M. Thomasson:

Can you create a little self-contained example that shows these >>>>>>>> warnings?

Make the pragmas commented and look what the IDE shows as warnings. >>>>>>>

Think about getting a warning free compile. Think about what these >>>>>> warnings actually mean. If you find a bug, report it to the MSVC
team.

Try this ...

void fn( unique_lock<mutex> &lock )
{
ÿÿÿÿÿassert(lock);
ÿÿÿÿÿlock.unlock();
}

... and you'll get a warning.

Fwiw, I get no warning with:

{
ÿÿÿÿ std::unique_lock<std::mutex> lock(m_mutex);
ÿÿÿÿ assert(lock);
ÿÿÿÿ lock.unlock();
ÿÿÿÿ //lock.unlock(); // this throws an exception.
}

That's sth. totally different. My function has the pre-condition
that it inherits the lock of the calling function and sometimes
it unlocks it.

Ahhh. I got them with:
__________________________________
namespace ct
{
ÿÿÿÿ struct mutex_test
ÿÿÿÿ {
ÿÿÿÿÿÿÿÿ std::mutex m_mutex;

ÿÿÿÿÿÿÿÿ void
ÿÿÿÿÿÿÿÿ bar(std::unique_lock<std::mutex>& lock)
ÿÿÿÿÿÿÿÿ {
ÿÿÿÿÿÿÿÿÿÿÿÿ assert(lock); // better be locked!
ÿÿÿÿÿÿÿÿÿÿÿÿ lock.unlock();
ÿÿÿÿÿÿÿÿ }

ÿÿÿÿÿÿÿÿ void
ÿÿÿÿÿÿÿÿ foo()
ÿÿÿÿÿÿÿÿ {
ÿÿÿÿÿÿÿÿÿÿÿÿ std::unique_lock<std::mutex> lock(m_mutex);
ÿÿÿÿÿÿÿÿÿÿÿÿ bar(lock); // beware. unlocks the damn thing!
ÿÿÿÿÿÿÿÿÿÿÿÿ lock.lock(); // okay...
ÿÿÿÿÿÿÿÿ }
ÿÿÿÿ };
}
__________________________________

Give the warnings:
__________________________________
Severityÿÿÿ Codeÿÿÿ Descriptionÿÿÿ Projectÿÿÿ Fileÿÿÿ Line Suppression
Stateÿÿÿ Details
Warningÿÿÿ C26115ÿÿÿ Failing to release lock 'this->m_mutex' in
function 'ct::mutex_test::foo'.ÿÿÿ ct_threads
D:\ct_dev\projects\ct_threads\ct_threads\ct_main.cppÿÿÿ 26

Warningÿÿÿ C26111ÿÿÿ Caller failing to release lock 'this->m_mutex'
before calling function 'std::unique_lock<std::mutex>::lock'.
ct_threads D:\ct_dev\projects\ct_threads\ct_threads\ct_main.cppÿÿÿ 26

Warningÿÿÿ C26110ÿÿÿ Caller failing to hold lock 'lock' before calling
function 'std::unique_lock<std::mutex>::unlock'.ÿÿÿ ct_threads
D:\ct_dev\projects\ct_threads\ct_threads\ct_main.cppÿÿÿ 18
__________________________________


You just have to be very careful with this type of logic. These
warnings elude to that.

Can't you read my code ?
That's still sth. completely different than what I did.

Keep in mind that your code disables those warnings. So, be sure to turn
them back on for any and all user code!

--- MBSE BBS v1.0.8.4 (Linux-x86_64)
* Origin: A noiseless patient Spider (3:633/280.2@fidonet)

Am 08.02.2024 um 22:28 schrieb Chris M. Thomasson:

Keep in mind that your code disables those warnings. So, be sure to turn them back on for any and all user code!

Locking and unlocking mutexes is trivial and I don't need any addtional
aid for that. And MSVC runtime gives me a debug message if I try to
unlock a non-locked mutex; that's sufficient for me. And the shown
code is never trapped in that way.


--- MBSE BBS v1.0.8.4 (Linux-x86_64)
* Origin: A noiseless patient Spider (3:633/280.2@fidonet)

On 2/9/2024 4:16 AM, Bonita Montero wrote:

Am 08.02.2024 um 22:28 schrieb Chris M. Thomasson:

Keep in mind that your code disables those warnings. So, be sure to
turn them back on for any and all user code!

Locking and unlocking mutexes is trivial and I don't need any addtional
aid for that. And MSVC runtime gives me a debug message if I try to
unlock a non-locked mutex; that's sufficient for me. And the shown
code is never trapped in that way.

I am saying that a user of your code might not want those warnings
disabled at all. So, you should turn them back on.

--- MBSE BBS v1.0.8.4 (Linux-x86_64)
* Origin: A noiseless patient Spider (3:633/280.2@fidonet)

Am 09.02.2024 um 20:43 schrieb Chris M. Thomasson:

I am saying that a user of your code might not want those
warnings disabled at all. So, you should turn them back on.

In my own translation units I don't re-enable those warnings.
In headers I disable certain warnings at the beginning of the
header and re-enable them at the end, so that these headers
won't disable those warnings for translation units of others
using my code.


--- MBSE BBS v1.0.8.4 (Linux-x86_64)
* Origin: A noiseless patient Spider (3:633/280.2@fidonet)

On 2/9/2024 9:11 PM, Bonita Montero wrote:

Am 09.02.2024 um 20:43 schrieb Chris M. Thomasson:

I am saying that a user of your code might not want those
warnings disabled at all. So, you should turn them back on.

In my own translation units I don't re-enable those warnings.
In headers I disable certain warnings at the beginning of the
header and re-enable them at the end, so that these headers
won't disable those warnings for translation units of others
using my code.

Yup. I think that would be the prudent thing to do. :^)

Okay.

--- MBSE BBS v1.0.8.4 (Linux-x86_64)
* Origin: A noiseless patient Spider (3:633/280.2@fidonet)