Monday, May 24, 2021

Digest for comp.lang.c++@googlegroups.com - 25 updates in 2 topics

Bonita Montero <Bonita.Montero@gmail.com>: May 25 05:50AM +0200

>> also employing a CV. A mutex plus a CV is almost the fastest
>> producer-consumer-mechanism (monitor-objects are the fastest).
 
> Is that a troll?
 
Why ?
"Chris M. Thomasson" <chris.m.thomasson.1@gmail.com>: May 24 09:32PM -0700

On 5/24/2021 8:50 PM, Bonita Montero wrote:
>>> producer-consumer-mechanism (monitor-objects are the fastest).
 
>> Is that a troll?
 
> Why ?
 
About the "monitor-objects are the fastest" comment... ;^)
Bonita Montero <Bonita.Montero@gmail.com>: May 25 06:40AM +0200

>> Why ?
 
> About the "monitor-objects are the fastest" comment... ;^)
 
I'm just ignoring lock-free queues because they're
impracicable because you've to poll.
"Chris M. Thomasson" <chris.m.thomasson.1@gmail.com>: May 24 10:07PM -0700

On 5/24/2021 9:40 PM, Bonita Montero wrote:
 
>> About the "monitor-objects are the fastest" comment... ;^)
 
> I'm just ignoring lock-free queues because they're
> impracicable because you've to poll.
 
Why do have to poll?
"Chris M. Thomasson" <chris.m.thomasson.1@gmail.com>: May 24 10:08PM -0700

On 5/24/2021 10:07 PM, Chris M. Thomasson wrote:
 
>> I'm just ignoring lock-free queues because they're
>> impracicable because you've to poll.
 
> Why do have to poll?
 
I mean: Why do you have to poll?
 
I am wondering what gives you this thought to begin with?
Bonita Montero <Bonita.Montero@gmail.com>: May 25 07:46AM +0200

> I mean: Why do you have to poll?
 
Lock-free queues always have to be polled on the consumer-side and,
depending on the implementation, also on the producer-side if the
queue is full (but boost shows that the producer-side is also pos-
sible with blocking).
"Chris M. Thomasson" <chris.m.thomasson.1@gmail.com>: May 24 11:12PM -0700

On 5/24/2021 10:46 PM, Bonita Montero wrote:
> depending on the implementation, also on the producer-side if the
> queue is full (but boost shows that the producer-side is also pos-
> sible with blocking).
 
Why?
Bonita Montero <Bonita.Montero@gmail.com>: May 25 08:19AM +0200

>> queue is full (but boost shows that the producer-side is also pos-
>> sible with blocking).
 
> Why?
 
Because lock-free is without waiting in the kernel.
"Chris M. Thomasson" <chris.m.thomasson.1@gmail.com>: May 24 11:20PM -0700

On 5/24/2021 11:19 PM, Bonita Montero wrote:
>>> sible with blocking).
 
>> Why?
 
> Because lock-free is without waiting in the kernel.
 
Why, again? You are missing key things here... Think...
Bonita Montero <Bonita.Montero@gmail.com>: May 25 08:22AM +0200

>> Because lock-free is without waiting in the kernel.
 
> Why, again? You are missing key things here... Think...
 
I'm not missing anything but you lack any knowledge how a lock-free
queue is implemented. If you don't wait in the kernel if there isn't
an item in the queue the only opportunity that is left is polling.
"Chris M. Thomasson" <chris.m.thomasson.1@gmail.com>: May 24 11:27PM -0700

On 5/24/2021 11:22 PM, Bonita Montero wrote:
 
> I'm not missing anything but you lack any knowledge how a lock-free
> queue is implemented. If you don't wait in the kernel if there isn't
> an item in the queue the only opportunity that is left is polling.
 
You are missing things again. Think! Remember back when you said that
mutexes must use CAS?
"Chris M. Thomasson" <chris.m.thomasson.1@gmail.com>: May 24 11:30PM -0700

On 5/24/2021 11:22 PM, Bonita Montero wrote:
 
> I'm not missing anything but you lack any knowledge how a lock-free
> queue is implemented. If you don't wait in the kernel if there isn't
> an item in the queue the only opportunity that is left is polling.
 
I can give you a generic waiting thing called an, oh wait. I want to see
if you can do it for yourself. I can encrypt my answer....
Bonita Montero <Bonita.Montero@gmail.com>: May 25 08:30AM +0200

>> an item in the queue the only opportunity that is left is polling.
 
> You are missing things again. Think! Remember back when you said that
> mutexes must use CAS?
 
I never said that because I implemended mutex with LOCK XADD a long
time ago. And this has nothing to do with that you don't understand
that lock-free programming isn't possible without polling.
Describe me a lock-free algorithm that works without polling !
Bonita Montero <Bonita.Montero@gmail.com>: May 25 08:32AM +0200

> I can give you a generic waiting thing called an, oh wait. I want
> to see if you can do it for yourself. I can encrypt my answer....
 
You're stupid. We're talking about whether a lock-free queue
is possible without polling. And it is obviously not; if it
wouldn't be, it wouldn't be lock-free.
"Chris M. Thomasson" <chris.m.thomasson.1@gmail.com>: May 24 11:32PM -0700

On 5/24/2021 11:30 PM, Bonita Montero wrote:
 
>> You are missing things again. Think! Remember back when you said that
>> mutexes must use CAS?
 
> I never said that
 
Really? Should I bring up the older thread?
 
"Chris M. Thomasson" <chris.m.thomasson.1@gmail.com>: May 24 11:33PM -0700

On 5/24/2021 11:32 PM, Bonita Montero wrote:
>> to see  if you can do it for yourself. I can encrypt my answer....
 
> You're stupid. We're talking about whether a lock-free queue
> is possible without polling. And it is obviously not
 
Why poll, when we can check the predicate then wait?
 
 
; if it
"Chris M. Thomasson" <chris.m.thomasson.1@gmail.com>: May 24 11:34PM -0700

On 5/24/2021 11:30 PM, Bonita Montero wrote:
> time ago. And this has nothing to do with that you don't understand
> that lock-free programming isn't possible without polling.
> Describe me a lock-free algorithm that works without polling !
 
http://fractallife247.com/test/hmac_cipher/ver_0_0_0_1?ct_hmac_cipher=27becd4634e98df52a89d06b2906ce8a7fdf24968475da63b3d57719e7eb01d4ab5f0e28d0a76c73883661af6abd0514412e774530b3af251b118a66f38c521f1bb4c5652c303411c9de7606f4690777a997ad6d65ac625c456673216ae073a067fd34e5f37010811231569824a22be1f5ab1ee525a30626b87986672f
Bonita Montero <Bonita.Montero@gmail.com>: May 25 08:34AM +0200

> Why poll, when we can check the predicate then wait?
 
Oh, boy, you're ultimately stupid.
If the predicate is false you've repeatedly check it.
So that's polling.
Lynn McGuire <lynnmcguire5@gmail.com>: May 24 08:46PM -0500

I am getting std::bad_alloc from the following code when I try to
reserve a std::string of size 937,180,144:
 
std::string filename = getFormsMainOwner () -> getOutputFileName ();
FILE * pOutputFile = nullptr;
errno_t err = fopen_s_UTF8 ( & pOutputFile, filename.c_str (), "rt");
if (err == 0)
{
std::string outputFileBuffer;
// need to preallocate the space in case the output file is a
gigabyte or more, PMR 6408
fseek (pOutputFile, 0, SEEK_END);
size_t outputFileLength = ftell (pOutputFile) + 42; // give it some slop
fseek (pOutputFile, 0, SEEK_SET);
outputFileBuffer.reserve (outputFileLength);
 
Any thoughts here on how to handle the std::bad_alloc in std::string
reserve ?
 
Thanks,
Lynn
Lynn McGuire <lynnmcguire5@gmail.com>: May 24 08:50PM -0500

On 5/24/2021 8:46 PM, Lynn McGuire wrote:
> reserve ?
 
> Thanks,
> Lynn
 
I am using Visual Studio C++ 2015 on a Windows 7 x86 PC with 16 GB of
ram. I am probably using a lot of ram already in my program.
 
Thanks,
Lynn
Lynn McGuire <lynnmcguire5@gmail.com>: May 24 08:52PM -0500

On 5/24/2021 8:50 PM, Lynn McGuire wrote:
> ram.  I am probably using a lot of ram already in my program.
 
> Thanks,
> Lynn
 
And I am building a Win32 program. Not a Win64 program.
 
Thanks,
Lynn
Lynn McGuire <lynnmcguire5@gmail.com>: May 24 10:33PM -0500

On 5/24/2021 8:46 PM, Lynn McGuire wrote:
> reserve ?
 
> Thanks,
> Lynn
 
I googled this problem and the predominating solution was to put the
std::string reserve into a try catch. I did so and it works like a
champ ! My first try catch.
 
try
{
outputFileBuffer.reserve (outputFileLength);
// now read the file into the preallocated buffer
while ((num = fread (buffer, sizeof (char), sizeof (buffer) - 1,
pOutputFile)) > 0)
{
// make sure that there is a trailing zero
buffer [num] = '\0';
outputFileBuffer += buffer;
total += num;
}
}
catch (...)
{
// nothing to catch since any error causes this code to bypass
}
}
 
Thanks,
Lynn
Lynn McGuire <lynnmcguire5@gmail.com>: May 24 10:35PM -0500

On 5/24/2021 10:33 PM, Lynn McGuire wrote:
> }
 
> Thanks,
> Lynn
 
Let's try this code instead:
 
try
{
outputFileBuffer.reserve (outputFileLength);
// now read the file into the preallocated buffer
while ((num = fread (buffer, sizeof (char), sizeof (buffer) - 1,
pOutputFile)) > 0)
{
// make sure that there is a trailing zero
buffer [num] = '\0';
outputFileBuffer += buffer;
total += num;
}
}
}
catch (...)
{
// nothing to catch since any error causes this code to bypass
}
 
Thanks,
Lynn
Paavo Helde <myfirstname@osa.pri.ee>: May 25 07:47AM +0300

25.05.2021 04:52 Lynn McGuire kirjutas:
 
>> Thanks,
>> Lynn
 
> And I am building a Win32 program.  Not a Win64 program.
 
The usable memory space in a Windows 32-bit program is limited to 2GB.
It can be increased to 3GB, but this does not buy you much.
 
Catching std::bad_alloc as you have done in other responses is trivial,
but now what? Your program still does not work as expected.
 
If you are dealing with strings in GB range then you really should start
thinking of switching over to x64 compilation (this will involve some
64-bit bugfixing if this is your first time). Either that, or you need
to redesign your code to read and write files in smaller pieces, which
might be a lot of work.
 
Also, ftell() returns a signed 32-bit value in Windows so what you have
written here will cease to work when your files grow larger than 2 GB.
Suggesting to always use 64-bit alternatives for handling file sizes and
positions, even in 32-bit programs. Unfortunately these alternatives are
not portable and one needs to take some extra care for supporting
different OS-es.
 
It's also strange to base the program logic on the size of an *output*
file. But there are probably reasons.
Juha Nieminen <nospam@thanks.invalid>: May 25 05:16AM

> while ((num = fread (buffer, sizeof (char), sizeof (buffer) - 1,
> pOutputFile)) > 0)
 
The standard mandates that sizeof(char) is 1. It cannot have any other
value.
 
> {
> // nothing to catch since any error causes this code to bypass
> }
 
If you are catching a memory allocation, why not catch it explicitly and
return an error code or print an informative error message or something
that indicates what happened, rather than silently failing and doing
nothing?
 
try
{
// your code here
}
catch(const std::bad_alloc& e)
{
// Could do, for example:
std::cout << "Memory allocation failed: " << e.what() << "\n";
}
catch(...)
{
std::cout << "Unknown excpetion thrown while trying to read file\n";
}
You received this digest because you're subscribed to updates for this group. You can change your settings on the group membership page.
To unsubscribe from this group and stop receiving emails from it send an email to comp.lang.c+++unsubscribe@googlegroups.com.
Posted by at

No comments:

Post a Comment

Subscribe to: Post Comments (Atom)