- Worst thing about 2020 C++ - 3 Updates
- Avoid excessive write cycles to block - 1 Update
- Initialising a thread_local object with ID of thread - 5 Updates
Paavo Helde <eesnimi@osa.pri.ee>: Aug 13 10:06AM +0300 13.08.2020 01:28 Sam kirjutas: >> C++? > Co-routines is the undisputed winner, hands down. A solution in search > of a problem. More like a solution which you need to poorly reinvent or work around when you don't realize you have *this* problem. If you don't have use for co-routines this does not mean nobody does. For example, I have not found use for std::list and I'm not complaining. |
"Alf P. Steinbach" <alf.p.steinbach+usenet@gmail.com>: Aug 13 03:38PM +0200 On 13.08.2020 09:06, Paavo Helde wrote: > when you don't realize you have *this* problem. > If you don't have use for co-routines this does not mean nobody does. > For example, I have not found use for std::list and I'm not complaining. Let's call it the continuations API. Because it's not support for general coroutines, just the special case of continuations (a.k.a. stackless coroutines). - Alf |
Brian Wood <woodbrian77@gmail.com>: Aug 13 03:18PM -0700 On Thursday, August 13, 2020 at 2:06:46 AM UTC-5, Paavo Helde wrote: > when you don't realize you have *this* problem. > If you don't have use for co-routines this does not mean nobody does. > For example, I have not found use for std::list and I'm not complaining. Years ago Gcc and Clang were making some progress on static exceptions. I'm wondering if that work has been totally derailed now by 2020 C++. Brian Ebenezer Enterprises |
Frederick Gotham <cauldwell.thomas@gmail.com>: Aug 13 02:19PM -0700 I want to use an SDcard as a circular buffer for storing raw binary data (one byte at a time). First thing I'll do is format an 4GB SDcard with one FAT32 partition, and then I'll create two files on the partition: position.bin (size = 1 megabyte ) data.bin (size = ~3.9 gigabytes) The location and size of these two files on the FAT32 partition will never change. Data will be written to the file "data.bin" byte after byte after byte, and then when the file is full, it will start again writing at the beginning of the file. The "current write position" will be a 64-Bit number stored in the file "position.bin". Of course this file only needs to be 8 bytes in size, however I've chosen to make it 1 megabyte for the following reason: I need to read up on this more, but I think SDcards are written to in 512-byte blocks at a time. In order to avoid wearing out the first block on the SDcard, I will initially store the "current write position" at Byte #0 in the file "position.bin", and then the next time I'll move it to Byte #512, and then next time I'll move it to Byte #1024, then Byte #1536, then Byte #2048. Does this sound like a good strategy to get as much longevity as possible out of the SDcard? I won't increment the "current write position" 1 byte at a time, probably more like one megabyte at a time (so the position marker could be 32-Bit). |
Juha Nieminen <nospam@thanks.invalid>: Aug 13 05:50AM > unsigned counter = 0; > while ( counter >= g_counter ); //spin until g_counter increments Spin loops are generally a really bad idea (unless you are, like, targeting some small 8-bit embedded CPU that doesn't really care, because it runs at 100% load all the time anyway. But then, you probably aren't running many threads in such a CPU anyway, so the only conclusion is that spin loops are bad.) Also, I don't understand the rationale in that 'counter' variable at all. Nothing modifies it. What is its purpose? > //Give threads a chance to start > std::this_thread::sleep_for(std::chrono::seconds(2)); How do you know it takes 2 seconds for the threads to "start"? Why 2 seconds and not some other completely arbitrary time? |
Juha Nieminen <nospam@thanks.invalid>: Aug 13 05:54AM > You need to join the threads. Or alternatively detach them. (There may be situations where you genuinely don't join threads. Doing a create-and-forget thread like "std::thread(func).detach();" can be useful sometimes.) |
"Chris M. Thomasson" <chris.m.thomasson.1@gmail.com>: Aug 12 11:00PM -0700 On 8/12/2020 10:54 PM, Juha Nieminen wrote: > (There may be situations where you genuinely don't join threads. > Doing a create-and-forget thread like "std::thread(func).detach();" > can be useful sometimes.) Detached threads can be sketchy, however they can be handled for sure. |
"Chris M. Thomasson" <chris.m.thomasson.1@gmail.com>: Aug 13 12:07AM -0700 On 8/12/2020 10:50 PM, Juha Nieminen wrote: >> unsigned counter = 0; >> while ( counter >= g_counter ); //spin until g_counter increments > Spin loops are generally a really bad idea Think of a special spin loop... Where it tries to do something else instead of spinning. In other words, if it can do some other real work, then that can be used as a backoff, in a sense. (unless you are, like, targeting |
"Chris M. Thomasson" <chris.m.thomasson.1@gmail.com>: Aug 13 12:12AM -0700 On 8/13/2020 12:07 AM, Chris M. Thomasson wrote: > Think of a special spin loop... Where it tries to do something else > instead of spinning. In other words, if it can do some other real work, > then that can be used as a backoff, in a sense. pseudo code... Perhaps something along the lines of: ________________________ void foo_lock(...) { while (! try_lock(...)) // a check... { // failed to grab the lock... if (try_to_do_something_else()) continue; lock(); //blocking return; } } ________________________ |
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. |
No comments:
Post a Comment