- reusing threads in c++ - 11 Updates
- OT: Github - 1 Update
- Best C++ IDE - 6 Updates
- MemPool for realtime systems is here... - 4 Updates
- MemPool for realtime systems was updated... - 2 Updates
- copy-on-write - 1 Update
| kushal bhattacharya <bhattacharya.kushal4@gmail.com>: Mar 03 10:35PM -0800 Suppose i am running multiple parrallel threads in my program.So can i reuse the idle parrallel threads in order to to do some new task for a different context.( I am assuming that the previously created parrallel threads are mostly in idle state when there is no event occuring on it). Thanks, Kushal |
| Marcel Mueller <news.5.maazl@spamgourmet.org>: Mar 04 08:21AM +0100 On 04.03.17 07.35, kushal bhattacharya wrote: > Suppose i am running multiple parrallel threads in my program.So can i reuse the idle parrallel threads in order to to do some new task for a different context. This is possible. The concept is usually called ->"thread pool". Tasks from a TODO queue are scheduled to free threads from the pool and the thread is put back into the queue if there is nothing to do instead of discarding it. This concept if often implemented by web servers. > ( I am assuming that the previously created parrallel threads are mostly in idle state when there is no event occuring on it). Well, "mostly" is not sufficient in any way. To get this concept working you need /know/ whether there is something to do. An important property is that the tasks must not block for longer e.g. at I/O operations while the thread is still allocated from the pool. This can be handled by using ->"asynchronous I/O". Many operating systems provide APIs for asynchronous I/O. The concept is to release the thread while waiting for I/O and allocate a new one from the pool as soon as the operating system notifies that the I/O has completed. However, in practice it depends on your platform and the number and latency of the concurrent I/O operations whether this is a good idea. I have worked on platforms where "start thread" was a machine instruction which took only half a dozen clock cycles. Managing a thread pool is by far more expensive than starting additional threads in this case. And using asynchronous I/O is a major change in the design of the program flow. Marcel |
| kushal bhattacharya <bhattacharya.kushal4@gmail.com>: Mar 04 01:57AM -0800 Suppose i start threads initially without initialiazing any work to do.Then with some conditions i check whether those threads are idle or not and accordingly i allocate task to those threads.Can i do that? |
| Melzzzzz <Melzzzzz@zzzzz.com>: Mar 04 11:06AM > Suppose i start threads initially without initialiazing any work to > do.Then with some conditions i check whether those threads are idle or > not and accordingly i allocate task to those threads.Can i do that? If you know how, yes. -- press any key to continue or any other to quit... |
| kushal bhattacharya <bhattacharya.kushal4@gmail.com>: Mar 04 03:55AM -0800 Actually i cant really figure out how to start it |
| Melzzzzz <Melzzzzz@zzzzz.com>: Mar 04 12:02PM > Actually i cant really figure out how to start it I recommend `C++ conurency in action` by Anthony Williams... -- press any key to continue or any other to quit... |
| kushal bhattacharya <bhattacharya.kushal4@gmail.com>: Mar 04 04:04AM -0800 ok thanks, but could u please give me a hint or so about how to look after it |
| Paavo Helde <myfirstname@osa.pri.ee>: Mar 04 05:44PM +0200 On 4.03.2017 8:35, kushal bhattacharya wrote: > Suppose i am running multiple parrallel threads in my program.So can i reuse the idle parrallel threads in order to to do some new task for a different context.( I am assuming that the previously created parrallel threads are mostly in idle state when there is no event occuring on it). Sure. The easiest way is to put tasks in a queue, then have N worker threads read the tasks from the queue, carry them out and post the results back to another queue. Nowadays standard C++ provides all the means for doing this, especially the std::condition_variable class. |
| kushal bhattacharya <bhattacharya.kushal4@gmail.com>: Mar 04 11:38AM -0800 hi actually i only have the scope to access from the callback function itself which is called when any read event is called on the socket.To be clear i am using libevent library of tcp sockets so i am created threads for parsing incoming packets which is possible from the read callback function.I only have access to this read callback function as the whole setup is runnning in an infinite loop as done from the libevent library to catch these callbacks.So i am thinking about creating a subthread within the parsing thread itself for notifying for any data pushed from the parsing thread.Is this the right approach? |
| kushal bhattacharya <bhattacharya.kushal4@gmail.com>: Mar 04 11:39AM -0800 Actually i am following the book concurrency of threads by anthony williams but since i havedo this task in a short period of time am not really sure about my approach |
| Dombo <dombo@disposable.invalid>: Mar 05 12:13AM +0100 Op 04-Mar-17 om 16:44 schreef Paavo Helde: > results back to another queue. > Nowadays standard C++ provides all the means for doing this, especially > the std::condition_variable class. Add to that the std::packaged_task and std::future classes, and it is almost trivial to implement a thread pool mechanism. If you don't have any specific requirements w.r.t. the thread the code runs on, the simplest solution would be to use std::async. |
| Jorgen Grahn <grahn+nntp@snipabacken.se>: Mar 04 11:09PM > make: Fatal errors encountered -- cannot continue > make: stopped in /usr/home/brian/tcp > I want something that works on FreeBSD, Linux, Windows, etc. The Makefile is written for GNU Make. I don't think the lowest common denominator of all build tools called "make"[0] is a good basis for a build system, when GNU Make is universally available. So on the BSDs I simply run gmake instead of make. (Except I never tried building this particular project on BSD before, and the libpcap stuff seems to be off, too.) /Jorgen [0] I haven't looked into the capabilities of BSD make. It may be powerful, but to be blunt, I don't have a reason to care. -- // Jorgen Grahn <grahn@ Oo o. . . \X/ snipabacken.se> O o . |
| Manfred <invalid@invalid.add>: Mar 04 12:49AM +0100 On 03/04/2017 12:08 AM, Ian Collins wrote: >> implementation is a priority. > As a novice, the OP is very unlikely to encounter standard compliance > issues with MSVC++, or gcc. Probably, definitely true with gcc. But it is also true that novices often like to experiment and try new things (I did at the time) - curiosity is the salt of the learning process, which can lead to surprises. OTOH I would not advise a novice to learn C++ by getting anywhere near CArray. > Most compliance issues are obscure or "advanced" issues. The current > large code base I'm working in builds with clang++, g++ and MSVC++ and > we don't have any compliance work-arounds for any of the compilers. I have no difficulty believing that. In production code you want to keep your distance from the corners of the standard. But I would not define the examples I have given (which I would say are unlikely to be the only ones) as 'obscure' code. If you look at the thread example, one would probably choose to use pointers instead of references in the task function, and then the issue would simply vanish, but still it is not that unreasonable code, is it? There the lesson is: "if you want to use pass-by-reference with threads, you have to be explicit about it", so use pointers or std::ref(). gcc would tell you that (well, force you to look for that) at compile time. VC++ would tell you nothing, and you'd have to find out when the program doesn't do what it is supposed to do. |
| legalize+jeeves@mail.xmission.com (Richard): Mar 04 12:36AM [Please do not mail me a copy of your followup] Manfred <invalid@invalid.add> spake the secret code >OTOH, being the OP a newbie, I think that correctness of the language >implementation is a priority. ...but the examples you cite aren't things that are going to be encountered by a newbie IMO. MFC? They ain't gonna use it IMO. Regarding std::thread, I'm not seeing the requirements in the standard that you are seeing. You keep talking as if the non-conformance to the standard is ubiquitous and commonplace, but you cited one example that has nothing to do with the standard and another that is dubious. Care to back up this statement: >My point is that, for what is worth, in my experience I have got many >more standard compliance issues with MSVC than with gcc Specifically the phrase "MANY MORE standard compliance issues". The last big one I was aware of had to do with expression SFINAE and that one has been fixed in the current release. -- "The Direct3D Graphics Pipeline" free book <http://tinyurl.com/d3d-pipeline> The Terminals Wiki <http://terminals-wiki.org> The Computer Graphics Museum <http://computergraphicsmuseum.org> Legalize Adulthood! (my blog) <http://legalizeadulthood.wordpress.com> |
| Bo Persson <bop@gmb.dk>: Mar 04 02:10AM +0100 On 2017-03-03 20:43, Manfred wrote: >> Since when is MFC part of the C++ standard? > This example is obviously primarily about quality of library code > (shipped with VC). This is a 25 year old library https://blogs.msdn.microsoft.com/vcblog/2017/02/27/happy-25th-birthday-mfc/ shipped with the compiler for backward compatibility. > Nevertheless it easy to see that copying objects of class type via > memcpy is in general a standard violation - you can't copy objects > without invoking copy constructors, right? Code shipped with a specific compiler doesn't have to be portable to every other compiler. It is very much allowed to use compiler specific features that turns formally UB code into implementation defined and working. Buy the compiler writer a beer, and suddenly your library code just works! Bo Persson |
| Paavo Helde <myfirstname@osa.pri.ee>: Mar 04 11:08AM +0200 On 4.03.2017 0:32, Manfred wrote: > entirely (obvious advice is use std), but since they are still shipping > them, the inexperienced user may inadvertently use them and get into > trouble. An inexperienced user might get into a trouble in C++ in thousand different ways. Yes, using an outdated and inconvenient library like MFC is one of those ways. > My point is that, for what is worth, in my experience I have got many > more standard compliance issues with MSVC than with gcc (with which I > substantially encountered none). Agreed, though for example I think there was a short time period when the 'override' specifier was just standardized, but the current latest gcc version did not have it (MSVC++ had had it already for years before). But in general yes, gcc has over years been much more standards compliant. > debugger and user friendliness are quite good to me. > OTOH, being the OP a newbie, I think that correctness of the language > implementation is a priority. Here I disagree, IMO for a newbie a good debugger is much more important, and here VS wins. A newbie would make a lot of copy-pasting from SO and other places, half of which are plain wrong or out of date and won't work anyway. The few problems caused by the compiler standard compliance issues would just go unnoticed in the myriad of other problems. |
| "Alf P. Steinbach" <alf.p.steinbach+usenet@gmail.com>: Mar 04 12:17PM +0100 On 3/4/2017 10:08 AM, Paavo Helde wrote: > gcc version did not have it (MSVC++ had had it already for years > before). But in general yes, gcc has over years been much more standards > compliant. g++ has generally been in advance wrt. core language evolution, while MSVC has generally been in advance wrt. standard library evolution. Especially regex-es and std threads took a very long time to become supported by g++ on the Windows platform; that was very annoying! On the whole I rather like the MSVC approach. The good library support is probably in large part due to STL (a funny name coincidence, STL maintaining the STL over at Microsoft). Still, I think it's like 10 to 15 years since I last reported a g++ compiler issue, while I report one such about every other month for MSVC. On the third hand, usually the Microsoft compiler team fix things fast, and usually they send just one notification per bug: hey, it's fixed. But on the fourth hand, yesterday I got yet another a notification, from a series, that a bug I reported about a year ago had finally been fixed: <url: https://connect.microsoft.com/VisualStudio/feedback/details/2256407/c-two-user-defined-conversions-incorrectly-accepted-in-implicit-conversion-sequence> And now I'm out of hands, I'm just a quadruped. So. Cheers!, - Alf |
| Manfred <noname@invalid.add>: Mar 04 08:02PM +0100 On 3/4/2017 1:36 AM, Richard wrote: >> implementation is a priority. > ...but the examples you cite aren't things that are going to be > encountered by a newbie IMO. As I wrote elsethread, I think that such examples are not really obscure code. Feel free to have a different opinion, of course. > MFC? They ain't gonna use it IMO. > Regarding std::thread, I'm not seeing the requirements in the standard > that you are seeing. I gave (as per your request) detailed references to the standard. I think that, if you read it, you will see it. That said, if you like a different interpretation of the standard, I have no intention to force you into anything. > You keep talking as if the non-conformance to the standard is > ubiquitous and commonplace, but you cited one example that has nothing > to do with the standard and another that is dubious. No I am not. I said /in my experience/ I have seen non-conformance with the MS compiler significantly(my personal measure, if you allow me) more often than with gcc(with which I found almost none). This is obviously _not_ saying that the MS compiler non-conformance is ubiquitous - this would be just silly. In fact I have said elsethread that I like the IDE as a whole, and I use it for my Windows code. If you allow me, I think I can mention some weak point I have happened to stumble into. >> My point is that, for what is worth, in my experience I have got many >> more standard compliance issues with MSVC than with gcc > Specifically the phrase "MANY MORE standard compliance issues". I will not make a detailed list of all I have encountered (I don't recall them all, and it would be of little interest besides being off-topic) Just because you ask, I may mention that my first MS C++ compiler was VC++ 5.0 Pro (back in the '90s), since then I used subsequent versions (not all). The examples I gave apply to VS2015. Along the line I have seen e.g. issues with template code of the early implementations, or C standard library APIs non-conforming (either semantically or syntactically) to modern C standards (I think the former have been fixed for quite some time, an example of the latter that comes to mind is vsnprintf which has not been C99 compliant until VS2015/Win10) I may add that I have had internal compiler errors (you may still find traces e.g. in the boost source tree that I was not the only one to experience such stuff) and code that would not compile correctly unless bracketed with #pragma optimize("g", {off/on}) - I personally categorize these together with noncompliances in the sense that the compiler was not doing what it was supposed to do (as the standard obviously requires). Besides this quite boring story (but since you asked...) on the other hand I have been using gcc since my time at university (earlier than MS VC++) and personally I never got a hiccup from it (except maybe only once a couple of years ago which ended up being a documentation issue) > The last big one I was aware of had to do with expression SFINAE and > that one has been fixed in the current release. Sure they fixed most stuff (I can't say all) along the line. Microsoft is a great company, they would be foolish (which they surely aren't) if they didn't. They have been catching up. My personal opinion is that they are the best for Windows code, not the best, for the compiler part and including the world outside Windows, if compared with gcc. |
| Ramine <toto@toto.net>: Mar 03 06:49PM -0500 Hello...... MemPool for realtime systems is here... Real-Time Memory Management In Delphi and FreePascal, memory management is normally performed using getmem,allocmem, freemem, reallocmem, etc. The run-time system's heap offers great flexibility and efficiency, but it cannot fulfil real-time requirements. The run-time requirements are non-deterministic. In addition, they may require blocking task switches, which makes them unusable for interrupt handlers. My following MemPool that uses generics offers memory management with real-time capabilities through Memory Pools. A Memory Pool is an isolated heap with data buffers as objects of equal size. Any number of memory pools can exist simultaneously. A pool is initialized once and allocated a certain number of buffers as objects. Thereafter, buffers as objects can be allocated and deallocated from the pool under real-time conditions. You can use it with Delphi 2009 and up on the following RTOS: Win32 API Compatible RTOS for 32/64-bit x86 Embedded Systems On Time's royalty-free hard real-time embedded operating system for 32/64-bit x86 CPUs implements a Windows subset kernel in only 16k of memory. It provides about 400 Win32 API functions and can load Windows DLLs. Read more here: http://www.on-time.com/rtos-32.htm http://www.on-time.com/rttarget-32.htm I will soon port my Threadpool engine so that you will be able to do realtime system programming with it. You can download MemPool from here: https://sites.google.com/site/aminer68/mempool-for-realtime-systems Thank you, Amine Moulay Ramdane. |
| Mr Flibble <flibbleREMOVETHISBIT@i42.co.uk>: Mar 04 01:25AM On 03/03/2017 23:49, Ramine wrote: > do realtime system programming with it. > You can download MemPool from here: > https://sites.google.com/site/aminer68/mempool-for-realtime-systems TStack does its own allocations and isn't real-time so you are doing it wrong. /Flibble |
| Ramine <toto@toto.net>: Mar 04 12:00PM -0500 On 3/3/2017 8:25 PM, Mr Flibble wrote: > TStack does its own allocations and isn't real-time so you are doing it > wrong. > /Flibble I have written DLList.pas that contains a new DStack that is real-time. Please download it again: https://sites.google.com/site/aminer68/mempool-for-realtime-systems Thank you, Amine Moulay Ramdane. |
| Mr Flibble <flibbleREMOVETHISBIT@i42.co.uk>: Mar 04 06:51PM On 04/03/2017 17:00, Ramine wrote: > I have written DLList.pas that contains a new DStack that is real-time. > Please download it again: > https://sites.google.com/site/aminer68/mempool-for-realtime-systems I will not download it again because it is Pascal and this is a C++ newsgroup (I have no interest in Pascal). Why do you insist on posting off topic Pascal to a C++ newsgroup? It is most irritating. /Flibble |
| Ramine <toto@toto.net>: Mar 04 12:17PM -0500 Hello... MemPool for realtime systems was updated... The previous TStack was not real-time, I have written DLList.pas that contains a new DStack that is real-time. Description: Real-Time Memory Management In Delphi and FreePascal, memory management is normally performed using getmem,allocmem, freemem, reallocmem, etc. The run-time system's heap offers great flexibility and efficiency, but it cannot fulfil real-time requirements. The run-time requirements are non-deterministic. In addition, they may require blocking task switches, which makes them unusable for interrupt handlers. MemPool that uses generics offers memory management with real-time capabilities through Memory Pools. A Memory Pool is an isolated heap with data buffers as objects of equal size. Any number of memory pools can exist simultaneously. A pool is initialized once and allocated a certain number of buffers as objects. Thereafter, buffers as objects can be allocated and deallocated from the pool under real-time conditions. You can use it with Delphi 2009 and up on the following RTOS: Win32 API Compatible RTOS for 32/64-bit x86 Embedded Systems On Time's royalty-free hard real-time embedded operating system for 32/64-bit x86 CPUs implements a Windows subset kernel in only 16k of memory. It provides about 400 Win32 API functions and can load Windows DLLs. Read more here: http://www.on-time.com/rtos-32.htm http://www.on-time.com/rttarget-32.htm And please look at test.pas demo inside the zipfile - compile and execute it... You can download MemPool from: https://sites.google.com/site/aminer68/mempool-for-realtime-systems Thank you, Amine Moulay Ramdane. |
| Ramine <toto@toto.net>: Mar 04 12:32PM -0500 On 3/4/2017 12:17 PM, Ramine wrote: I mean: The previous TStack was not making MemPool real-time, I have written DLList.pas that contains a new DStack that makes MemPool real-time. Thank you, Amine Moulay Ramdane. |
| SG <s.gesemann@gmail.com>: Mar 04 08:37AM -0800 Am Freitag, 3. März 2017 08:55:26 UTC+1 schrieb Alf P. Steinbach: > `std::forward` reduces to a `std::move`, I believe, and anyway I'd write > `std::move` there in order to not mislead myself and others – I find > the magic of `std::forward` a bit impenetrable. If you write std::move in such a context, you have to be sure that T is never going to be a reference type. Template argument deduction is not necessary to turn T into a lvalue reference type. Of course, in this case, it makes little sense to try to instantiate something like a cow<int&>. But I can point to you an example, where the use of std::forward over std::move in such contexts actually prevents accidental moves: tuple<string&>. Consider this situation: string a = "a"; string b; tie(b) = tie(a); // does this invalidate a ? The relevant assignment operator is this one: tuple<string&>& tuple<string&>::operator=(tuple<string&>&& rhs) and it uses std::forward<string&> instead of std::move so that an lvalue string expression is assigned to b and a is not moved from. My suggestion for what to use in such general template contexts is one of the following two options: (1) std::forward (also works if T can be an lvalue reference) (2) std::move with an in-class static assert that ensures T is never going to be an lvalue reference. I wouldn't use std::move without ensuring that T is an object type. > Cheers!, > - Alf Cheers! sg |
| 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