- Debug trace of Halts() deciding halting on H_Hat() ---Halts returns a value to main() - 1 Update
- Tricky bug - 18 Updates
- "Is C++ type-safe? (There's two right answers) - 2 Updates
- Onwards and upwards - 3 Updates
- Refuting the {Linz, Sipser, Kozen} HP Proofs (Ben's example) - 1 Update
| Jorgen Grahn <grahn+nntp@snipabacken.se>: Dec 17 09:10PM On Thu, 2020-12-17, Juha Nieminen wrote: ... >> minds." Einstein > It's the archetypal sign of a pseudoscientist to quote Einstein (often > with a misquote) to try to justify his wacky conjectures. /Please/ resist the urge to respond to crap like this. /You/ know he's a crank, /I/ know it, /he/ has surely been told for years (by people with "mediocre minds") -- no need to give him a free ticket past everyone's killfile [1]. /Jorgen [1] This is probably a mixed metaphor, but I like it :-) -- // Jorgen Grahn <grahn@ Oo o. . . \X/ snipabacken.se> O o . |
| scott@slp53.sl.home (Scott Lurndal): Dec 15 05:03PM >> bug. >Joinining in destructor was always no no if Java model is used. >Not once I saw pworblems with this in RL. bool in_context(void) const { return t_thread == pthread_self(); } c_thread::~c_thread(void) { lock(); terminate(); unlock(); } /** * Terminate the thread. If called in-context, it will clear the * running flag and exit. If called out of context, it will cancel * the thread and join with it. */ void c_thread::terminate(void) { if (in_context()) { t_running = false; pthread_exit(NULL); } else { int diag = pthread_cancel(t_thread); if (diag == ESRCH) { /* Thread already gone, nothing to do */ } else if (diag != 0) { t_logger->log("%s Unable to cancel thread: %s\n", t_thread_name, strerror(diag)); } void *rval; diag = pthread_join(t_thread, &rval); if (diag == ESRCH) { /* Thread already gone, nothing to do */ } else if (diag != 0) { t_logger->log("%s Thread join failed: %s\n", t_thread_name, strerror(diag)); } t_running = false; } |
| "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com>: Dec 15 01:50PM -0800 On 12/15/2020 2:23 AM, Bonita Montero wrote: > Yes, but only if the mutex is locked. > Sorry, but you seem to be too stupid to read < 250 lines of > trivial code. I only had time to briefly skim it. |
| "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com>: Dec 17 11:45AM -0800 On 12/15/2020 6:38 AM, Chris Vine wrote: >> that has this race condition, to the point where I thought it was a >> common mistake. Would cringe every time I would see a thread base class. > Hopefully this particular wrongness is becoming a thing of the past. Alas, I am not nearly as active as I was around 15-20 years ago wrt programing threads and creating synchronization algorithms. However, I share in your hope! :^) Remember use a lot of assembly language in x86 and SPARC to create sensitive sync algorithms. Ahhh, the good ol' days when comp.programming.threads was actually useful. Now, it seems to be a wasteland. Got to know really smart people on there, like David Butenhof. I miss conversing with him. There was the great lock-free debates on c.p.t. > thread class with a pure virtual function called "start" or some > similar name, which you would override by inheritance with the concrete > implementation of the code to be executed by the thread in question. Indeed. Pre-C++11, where people were using either POSIX or Windows for threading. I used a lot of C, but when it came to "wrapping" threads in C++, the almighty base class was used a lot. Argh! > Nowadays you just pass in a lambda function or std::function object > containing the implementation to your thread class, which obviates all > that: std::thread is not intended to be derived from. That is a good thing. |
| Bonita Montero <Bonita.Montero@gmail.com>: Dec 17 08:49PM +0100 > Remember use a lot of assembly language in x86 and SPARC to create > sensitive sync algorithms. ... Really ? Intrinsics for atomic variable accesses have been there for a long time. |
| "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com>: Dec 17 11:53AM -0800 On 12/16/2020 10:22 PM, Bonita Montero wrote: >> Using detached threads can be a bit sketchy. I never really found a >> need to actually use them. > I don't need the thread-objects after creation. Your thread pool is a bit different than the usual. Basically, a "vanilla" thread pool would simply create one or two threads per CPU, and those would stay there until pool destruction. To destroy the pool, one would send a special message that would cause a thread to terminate. So, send the "death" messages, then join all of the threads... I remember creating many experiments for the method of a user sending work to the pool. Kind of a network of distributed queues. It was layered. Each thread had their own local queues, then there was a bunch of global queues. I used an "eventcount" thing I made to allow for an efficient way for a work thread to wait on its local queues _and_ the global queues, all in one. Man, I loved that eventcount! Btw, its nothing like a semaphore. |
| "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com>: Dec 17 11:56AM -0800 On 12/17/2020 3:46 AM, Bonita Montero wrote: >> I have heard the same argument for ages. > I'm not using any freaky Lock-free synchronization > but only standard parts. Yeah, but I have seen many people mess up locking as well. One time, around 18 years ago... One person said all is good... The system has been running non-stop for around a month. Then, all of a sudden... BAM! Deadlock. I helped debug it. It was a bitch and a half. |
| "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com>: Dec 17 12:04PM -0800 On 12/17/2020 3:44 AM, Bonita Montero wrote: >> please use proper quoting? > That was a minor bug. It wouldn't cause any malfunctions but only > that a threads might release its resources when it times out. Still, it does not hurt to run it through, say, ThreadSanitizer: Just for fun? >>> The non-trivial parts are tested. >> How did you test them? > With code that uses this thread-pool. Okay. |
| "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com>: Dec 17 12:07PM -0800 On 12/17/2020 11:49 AM, Bonita Montero wrote: > > Remember use a lot of assembly language in x86 and SPARC to create > > sensitive sync algorithms. ... > Really ? Really. Big time. > Intrinsics for atomic variable accesses have been there for a long time. They were not standard. Using ASM was for piece of mind. Did you ever hear of an old GCC bug that would break POSIX, well before C++11? It was a mutex issue. I might try to dig up the old message. |
| "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com>: Dec 17 12:09PM -0800 On 12/17/2020 11:49 AM, Bonita Montero wrote: > > sensitive sync algorithms. ... > Really ? > Intrinsics for atomic variable accesses have been there for a long time. This was because C did not not know about threading. If it claimed to be POSIX compliant, okay, but there were still issues with memory barriers and exotic lock-free and wait-free algorithms. C had no idea about them. |
| Bonita Montero <Bonita.Montero@gmail.com>: Dec 17 09:13PM +0100 > and those would stay there until pool destruction. To destroy the pool, > one would send a special message that would cause a thread to terminate. > So, send the "death" messages, then join all of the threads... The number of threads need to be equally to the number of cores to have a full load if all threads are running; therefore you can set the number of threads to zero which defaults to the number of hw-threads. When you need more threads there are two cases. First your threads also should staturate your CPU, but threads might regulary waiting on events and leave compution-time to other threads in the pool. Second if you need an equal share of the computation time among all tasks the pool theoretically wouldn't have an upper limit and the use of the pool would be only that you have less costs than with creating individual threas. In this case my approach with a timeout for the threads is very useful: the timeout would keep running the threads for a coninous burst of tasks, but if that burst ends the threads give up their resources after a while. |
| Bonita Montero <Bonita.Montero@gmail.com>: Dec 17 09:15PM +0100 > around 18 years ago... One person said all is good... The system has > been running non-stop for around a month. Then, all of a sudden... BAM! > Deadlock. I helped debug it. It was a bitch and a half. Where should I have induced a deadlock ? The version of the thread-pool I've shown lately uses only one mutex. |
| Bonita Montero <Bonita.Montero@gmail.com>: Dec 17 09:18PM +0100 >> that a threads might release its resources when it times out. > Still, it does not hurt to run it through, say, ThreadSanitizer: Just > for fun? You don't have the concentration to trust in your work as you seem a bit chaotic; that's not uncommon for people who are interested in performance-programming because an affinity of thinking at the resource -level is often bound to mental issues. |
| Bonita Montero <Bonita.Montero@gmail.com>: Dec 17 09:24PM +0100 > They were not standard. ... When you are bound to gcc only you could use these intrinsics portably across different CPUs (__sync_*). And clang supports them compatibly for a while. MSVC also has atomic intrinsics for a long time. So you simply could have some #ifdefs to do the small part of the code which can't be shared among the platforms. And even with C++11 there could be reasons to use these intrinsics instead of the C++11-atomics because C++11 doesn't support DCAS. |
| "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com>: Dec 17 12:50PM -0800 On 12/17/2020 12:15 PM, Bonita Montero wrote: >> BAM! Deadlock. I helped debug it. It was a bitch and a half. > Where should I have induced a deadlock ? > The version of the thread-pool I've shown lately uses only one mutex. Iirc, they forgot to unlock a mutex under a very hard to trip condition. It was a distributed system, so, this one unlocked mutex was just a ticking time bomb for a deadlock. It was in C with no scoped locking semantics, no automatic unlocking, it was 100% manual. |
| Bonita Montero <Bonita.Montero@gmail.com>: Dec 17 09:56PM +0100 > It was a distributed system, so, this one unlocked mutex was just a > ticking time bomb for a deadlock. It was in C with no scoped locking > semantics, no automatic unlocking, it was 100% manual. What I said was related to what I did and not abou your anecdotes. |
| "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com>: Dec 17 12:57PM -0800 On 12/17/2020 12:18 PM, Bonita Montero wrote: > a bit chaotic; that's not uncommon for people who are interested in > performance-programming because an affinity of thinking at the resource > -level is often bound to mental issues. You are an odd person. Anyway, imvvho, using ThreadSanitizer is okay. Using Relacy is alright. No problem. Then there is the opposite argument. Trusting in your work in one thing... Then seeing how its subtly broken in a obscure part using a race detector is another. Large programs can get complex. |
| "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com>: Dec 17 12:59PM -0800 On 12/17/2020 12:56 PM, Bonita Montero wrote: >> was just a ticking time bomb for a deadlock. It was in C with no >> scoped locking semantics, no automatic unlocking, it was 100% manual. > What I said was related to what I did and not abou your anecdotes. You are to terse. I was just trying to have a conversation. |
| "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com>: Dec 17 01:05PM -0800 On 12/17/2020 12:24 PM, Bonita Montero wrote: >> They were not standard. ... > When you are bound to gcc only you could use these intrinsics portably > across different CPUs (__sync_*). It was actually easier for me to use GAS to assemble all of my sync code way back then. It gave me piece of mind. I wrote several versions, in x86, SPARC and some PPC. Back then, there was a lot of issues for compiler optimization, or the worst... Link time optimization to break things. Then the GCC mutex issue, breaking POSIX rules. > can't be shared among the platforms. > And even with C++11 there could be reasons to use these intrinsics > instead of the C++11-atomics because C++11 doesn't support DCAS. Well, getting DWCAS on x86 required ASM way back then. Iirc, there was no intrinsic on it, CMPXCHG8B, 20 years ago. There was a lot of issues before threading and atomics actually became _standard_, within the languages themselves, C and C++. |
| spuddy@isnotyourbuddy.co.uk: Dec 15 02:11PM On Tue, 15 Dec 2020 05:36:40 -0800 (PST) >> C++ model in which you just add value to pointer?=20 >The unsafe operations are useful only in limited occasions and >in limited meanings even in low level embedded code. But when needed they're REALLY needed. >So it is anyway good idea to make unsafe things like pointer >arithmetic or type punning to be ugly and inconvenient to express. How is pointer arithmetic inconvenient to express? It couldn't be any simpler. >Totally different question is if need of type punning a pointer into >integral value and back is best uglifier factor but it works.=20 Oh yeah, that would really make the code clearer. >Bad code that does naked casts and pointer arithmetic all >over the place will look like garbage it is and so mission >accomplished.=20 I've found that people who have a problem with pointer arithmetic don't really understand it. Or pointers. |
| spuddy@isnotyourbuddy.co.uk: Dec 15 04:25PM On Tue, 15 Dec 2020 07:29:49 -0800 (PST) >> >integral value and back is best uglifier factor but it works.=20 >> Oh yeah, that would really make the code clearer. >Yes, the unsafe stuff stands out so it is more clear that it is unsafe. Illogical reasoning. Any experience developer knows to be careful with pointers, they don't need it signposted. >can program years in C++ without doing any pointer arithmetic >ever and so quite many can make errors in it. It saves my time when >I find problematic places quicker. Sure, you can program in C++ without ever using pointers if you only ever program baby code. But if you ever do for example any network packet processing or are writing a parser, using shared memory or to-the-metal you'll soon get sick of trying to do it all with std::string/array or some other higher level abstraction not to mention how slow they'd be. If you only want to use high level constructs perhaps you'd be better off with Java or Python. |
| Brian Wood <woodbrian77@gmail.com>: Dec 17 07:27AM -0800 On Thursday, December 17, 2020 at 8:01:23 AM UTC-6, David Brown wrote: > Getting recursive lambdas to work can be an interesting challenge. But > I don't know why you'd want to do so here - the template functions are > fine, and IMHO clearer than lambdas. I was wondering if they would be a clearer or shorter way to do it, but agree they aren't in this case. Thanks for posting all of that. |
| David Brown <david.brown@hesbynett.no>: Dec 15 05:07PM +0100 On 15/12/2020 16:25, Brian Wood wrote: >> tactics. > Noah and his family spent decades working on the ark > before there was a drop of rain. You are not Noah, you are not building an ark, and you are not working on mystical orders from a god. You are making a software system that has no users, and no sign of any users in the future - at least partly because you are personally ensuring that no one will want to use it. Take a look at yourself in the mirror, and throw out the narcissism and megalomania, and the martyr complex. Get a bit of realism in your life. You are just a programmer - no more, no less. Make something that people will find useful - or find out what people want, and make that. Don't keep telling people you are the reincarnation of Noah and expect them to come to your door. > That might have made sense in the past, but due to > the Chinese government, those that haven't died > from the virus are often having a hard time financially. Take your wild conspiracy theories and fanatic politics elsewhere. You are not doing yourself any favours. Yes, much of the world is having more challenges economically after this past year. That has not stopped people and companies investing in things that make economic sense. If your software is good, and will save users money (since they don't have to develop similar functionality themselves), then you can sell it. > My efforts are open to intelligent, hard-working > people, who through no fault of their own, happen to > be poor. Proper open source is fine - but it's not easy to make a business from it if the code is all you have. Free software with paid support and consultancy is one way to make it work. But you are saying the software is free (but not open), while the consultancy and support is so bad that you do it for free, and the software is so difficult to use that you will spend weeks of effort so that people will be able to use the zero-cost software. Do you really not understand how that looks? > I hope we can get over the doubts and start to believe > that the time has come for on-line code generation. Belief is not sufficient. No one has seen /any/ reason to suggest that on-line code generation is a good idea, or that its "time" has come. You have told us repeatedly, year after year, how wonderful this concept is, how much it is the greatest revolution since sliced bread, and how you are ready to take over the world with it. Yet as far as I can remember, you have not once given a /single/ reason. Not the slightest hint of a potential benefit. /Nothing/. > The kicking and screaming gets old. Exactly. Stop kicking and screaming. If you have some justification for why anyone should want to use your software, or want to use on-line code generation, then you could start with that. > You do a good > job though of pretending to be objective. > We now return you to your regularly scheduled programming... If you want to discuss something technical about some code, remove the advertising for your software and then post it in a new thread. Make a compilable code snippet, learn to use the space key so that it is legible, and maybe someone here will be willing and able to help. But as long as people think it is just advertising for your business, or that you are going to wander off into religious or political fanaticism again, you will have trouble finding willing help. |
| scott@slp53.sl.home (Scott Lurndal): Dec 15 05:06PM >The software is more mature and versatile than a year ago. >SaaS is doing well. As far as I can tell I'm sitting on a >gold mine. Sure. >"In G-d we trust" has been the national motto of the US >for many years. That trust extends to how you build >and run a business. Actually, for less than 70 years. It was added to counter the "godless communists" during the height of the cold war by religious nutcakes. >I don't know if you're prying, but am thinking about >Samson and Delilah. A fairy tale from a collection of fireside stories. |
| olcott <NoOne@NoWhere.com>: Dec 17 09:07AM -0600 On 12/17/2020 8:34 AM, Ben Bacarisse wrote: > the "outer" assessment must get an infinite number of cases wrong. We > won't get to see that, though. In fact, I doubt it even exists except > for a couple of special cases. All that I have to do to refute the {Linz, Sipser, and Kozen} proofs is to show how Halts decides their {Ĥ, D, and N} counter examples as a function of their sequence of instructions that Halts simulates. A simulator has access to the sequence of instructions that it simulates. A partial halt decider that correctly decides the counter-example basis of the conventional halting problem proofs is sufficient to refute these proofs. -- Copyright 2020 Pete Olcott "Great spirits have always encountered violent opposition from mediocre minds." Einstein |
| 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