| "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com>: Feb 21 09:47PM -0800 On 2/21/2021 10:58 AM, Bonita Montero wrote: >> it is clearly worse. > You can't compare that to the discussed issue because there's no > opportunity to capture all the CPU-time by one task. Why not? |
| Bonita Montero <Bonita.Montero@gmail.com>: Feb 22 06:51AM +0100 >> You can't compare that to the discussed issue because there's no >> opportunity to capture all the CPU-time by one task. > Why not? Not how he defined it. |
| Bonita Montero <Bonita.Montero@gmail.com>: Feb 22 06:52AM +0100 > The key point isn't what resource was being managed, but how do we > really define 'fair'. ... But with an example that doesn't fit with the discussion. Chris does know what I mean, you don't. |
| Bonita Montero <Bonita.Montero@gmail.com>: Feb 22 06:54AM +0100 > I agree. Fwiw, my rwmutex does not allow readers to starve out writers > and vise versa. ... Building such a RW-mutex is impossible. You can't prevent a writer or reader to hold the mutex as long as he wants. |
| "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com>: Feb 21 10:00PM -0800 On 2/21/2021 9:54 PM, Bonita Montero wrote: >> and vise versa. ... > Building such a RW-mutex is impossible. You can't prevent a writer or > reader to hold the mutex as long as he wants. True, you have again snipped out the relevant issue of classic starvation I posted where frequent heavy read activity can stave out writers, and vise versa. You are familiar with reader/writer priority on rwmutex right? My impl alternates them in batches. |
| "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com>: Feb 21 10:01PM -0800 On 2/21/2021 9:51 PM, Bonita Montero wrote: >>> opportunity to capture all the CPU-time by one task. >> Why not? > Not how he defined it. Well, lets say five threads have read access... There is nothing stopping them from using all cpus! |
| "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com>: Feb 21 10:10PM -0800 On 2/21/2021 9:52 PM, Bonita Montero wrote: >> really define 'fair'. ... > But with an example that doesn't fit with the discussion. > Chris does know what I mean, you don't. I do know what you mean, its just not the classic way of thinking about starvation. You are 100% correct that a batch of readers, or a single writer can hold the lock for hours. It can happen, well, its not advised, but it still can occur. |
| Bonita Montero <Bonita.Montero@gmail.com>: Feb 22 07:40AM +0100 > starvation I posted where frequent heavy read activity can stave > out writers, and vise versa. You are familiar with reader/writer > priority on rwmutex right? My impl alternates them in batches. That doesn't make fairness. |
| Bonita Montero <Bonita.Montero@gmail.com>: Feb 22 09:20AM +0100 > You are familiar with reader/writer priority on > rwmutex right? My impl alternates them in batches. That doesn't make fairness. |
| "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com>: Feb 22 02:54PM -0800 On 2/22/2021 12:20 AM, Bonita Montero wrote: >> You are familiar with reader/writer priority on rwmutex right? My impl >> alternates them in batches. > That doesn't make fairness. My version of "fairness", or being "starvation free", is when readers cannot starve out writers, and vise versa. Oh well. :^) |
| Lynn McGuire <lynnmcguire5@gmail.com>: Feb 22 04:14PM -0600 "What Will Die Out Sooner C++ or C++ Programmers?" by Oleksandr Kaleniuk https://medium.com/swlh/what-will-die-out-sooner-c-or-c-programmers-f4659dc243c0 "Until just yesterday, I thought AI will never replace me as a programmer." AI is never gonna replace me, I won't live that long. Lynn |
| Juha Nieminen <nospam@thanks.invalid>: Feb 22 10:06AM > lol! :^D > I just never found the need to include .c file. However I have had to > work on code that did do that. Shit happens. :^) Sometimes including a source file (not a header file) may be the most practical way of dealing with generated code. The most common case of this probably being an array of values in the form of C/C++ source code generated by a program, perhaps even your own program. If you want this array to have internal linkage (ie. you want it to be "static") and you want to be able to write code in that compilation unit that uses the array, then this is basically the only option. And I don't think there's anything wrong with it. (The only other option is to put the array in its own compilation unit and have it have external linkage. This pollutes the global namespace and hinders possible compiler optimizations in the code that uses the array.) |
| David Brown <david.brown@hesbynett.no>: Feb 22 11:59AM +0100 On 22/02/2021 11:06, Juha Nieminen wrote: > (The only other option is to put the array in its own compilation unit and > have it have external linkage. This pollutes the global namespace and > hinders possible compiler optimizations in the code that uses the array.) I have done exactly that with generated code. But I usually give it a specific extension such as ".inc" to distinguish it from ordinary human-written C or C++ files. This is not the /only/ option, but it is often the most convenient one. (At least some arrays that could only be generated with external programs can now be done using compile-time calculations in C++. I'd probably use that for CRC tables and the like in new code. But that won't work for everything.) |
| Kaz Kylheku <563-365-8930@kylheku.com>: Feb 22 03:21PM > practical way of dealing with generated code. The most common case of this > probably being an array of values in the form of C/C++ source code generated > by a program, perhaps even your own program. Both .h and .c files are source files. A source file that is #include -d should have a .h suffix, even if it contains definitions that would prevent it from being included in more than one place. Using .c for include files causes confusion; it is a deeply entrenched convention that .c means "I am the root file of a translation unit". If that is a lie, you are flouting the deeply rooted convention, and should be whipped naked with a wet noodle. > internal linkage (ie. you want it to be "static") and you want to be able > to write code in that compilation unit that uses the array, then this is > basically the only option. And I don't think there's anything wrong with it. You have the excellent option of naming it with a .h suffix. -- TXR Programming Language: http://nongnu.org/txr Cygna: Cygwin Native Application Library: http://kylheku.com/cygnal |
| antispam@math.uni.wroc.pl: Feb 22 06:41PM > included in more than one place. > Using .c for include files causes confusion; it is a deeply entrenched > convention that .c means "I am the root file of a translation unit". What about file that includes itself? It is both "root" and included. > If that is a lie, you are flouting the deeply rooted convention, > and should be whipped naked with a wet noodle. My convention is that .h specifies interface. I prefer something like '.def' or '.inc' for file that is included in specific places (specific context) and would not work otherwise. -- Waldek Hebisch |
| Joe Pfeiffer <pfeiffer@cs.nmsu.edu>: Feb 22 11:45AM -0700 >> convention that .c means "I am the root file of a translation unit". > What about file that includes itself? It is both "root" and > included. I find it hard to imagine a clearer indication of badly, badly broken code than a file that includes itself. |
| Kaz Kylheku <563-365-8930@kylheku.com>: Feb 22 06:49PM ["Followup-To:" header set to comp.lang.c.] >> convention that .c means "I am the root file of a translation unit". > What about file that includes itself? It is both "root" and > included. Obviously, the conventions have to be relaxed if we are to make submissions to IOCCC. In production code, if you need such a thing, you can split it into a non-self-referential .c part, and a self-referential .h part. You can always find content for that .c part that doesn't have to be in the .h part. If nothing else, then a copyright header. -- TXR Programming Language: http://nongnu.org/txr Cygna: Cygwin Native Application Library: http://kylheku.com/cygnal |
| Kaz Kylheku <563-365-8930@kylheku.com>: Feb 22 06:50PM >> convention that .c means "I am the root file of a translation unit". > What about file that includes itself? It is both "root" and > included. Obviously, the conventions have to be relaxed if we are to make submissions to IOCCC. In production code, if you need such a thing, you can split it into a non-self-referential .c part, and a self-referential .h part. You can always find content for that .c part that doesn't have to be in the .h part. If nothing else, then a copyright header. -- TXR Programming Language: http://nongnu.org/txr Cygna: Cygwin Native Application Library: http://kylheku.com/cygnal |
| 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