- std::condition_variable::wait_for - 4 Updates
- Machine code!!! \o/ - 3 Updates
- Threading Review/Feedback - 2 Updates
- Pointer use after delete - 1 Update
- dealing with multi byte characters - 1 Update
| Chris Vine <chris@cvine--nospam--.freeserve.co.uk>: Sep 01 11:34PM +0100 On Tue, 01 Sep 2015 14:56:39 -0500 > I think I got it. Lamda Expression capturing this. > while(!m_stopCV.wait_for(lock, std::chrono::seconds(10), > [this](){return m_stop;}) ) This is not right. The return value of the version of std::condition_variable::wait_for() which takes a predicate indicates whether the predicate is true or not when the timeout occurs (it returns false if there was a timeout without the predicate becoming true, otherwise true). You don't want to loop on it again: it already contains its own while loop to guard against spurious wake-ups (see §30.5.1/32). Also, will this code compile without the lambda body being 'return this->m_stop' - I can't remember if there is some implicit application of the this pointer to m_stop in the lambda body but I thought not? In summary, your while loop effectively overrides the timeout. If you don't want a timeout, use plain std::condition_variable::wait(). On your mutex point, you always call std::condition_variable::wait{for|until}() with the mutex locked. If the condition variable waits it releases the mutex by itself. On awakening it automatically reacquires the mutex. So m_stop is always tested under the mutex. One other consequence of this is that no more than one thread can proceed at a time if you do a broadcast on the condition variable - each thread after the first will block until it can acquire the mutex after the previously acquiring thread has released it. Chris |
| Chris Vine <chris@cvine--nospam--.freeserve.co.uk>: Sep 01 11:56PM +0100 On Tue, 01 Sep 2015 20:02:26 GMT > are accessing memory directly, then you need to worry about > volatile accesses to the predicate vis-a-vis compiler > optimizations. No you don't, unless your "accessing memory directly" involves things like mmap'ed memory which another process may be mutating. So far as concerns threads, volatile is never sufficient because it doesn't avoid a data race (it doesn't synchronise) and only serves to suppress acceptable optimizations for multi-threaded code. Nor is it necessary - atomic variables and mutexes act as compiler reordering barriers as well as carrying out synchronization. Volatile is a waste of time with threads. And in relation to condition variables, since you enter a condition variable wait with the mutex locked, the condition variable test will automatically be synchronized by the mutex. Chris |
| Christopher Pisz <nospam@notanaddress.com>: Sep 01 06:00PM -0500 On 9/1/2015 5:34 PM, Chris Vine wrote: > thought not? > In summary, your while loop effectively overrides the timeout. If you > don't want a timeout, use plain std::condition_variable::wait(). That's not the behavior I am seeing. It outputs "tick..." every 10 seconds, as expected. I want to loop, because the loop is where the task for the thread is done. Unless you are implying that the work goes in the lamda..are you? > On your mutex point, you always call > std::condition_variable::wait{for|until}() with the mutex locked. Isn't that what I am doing? std::unique_lock<std::mutex> lock(m_stopMutex); <--locks? while(!m_stopCV.wait_for(lock, std::chrono::seconds(10), [this](){return m_stop;}) ) { > the condition variable waits it releases the mutex by itself. On > awakening it automatically reacquires the mutex. So m_stop is always > tested under the mutex. Good, I was hoping so. I couldn't find it explicitly stated in the doc. > than one thread can proceed at a time if you do a broadcast on the > condition variable - each thread after the first will block until it can > acquire the mutex after the previously acquiring thread has released it. Only when the broadcast is done? That would be ok, because all they are going to do is go and exit. As long as the body of the while loop can be executed in more than one thread at a time. |
| Christopher Pisz <nospam@notanaddress.com>: Sep 01 06:03PM -0500 On 9/1/2015 6:00 PM, Christopher Pisz wrote: > Only when the broadcast is done? That would be ok, because all they are > going to do is go and exit. As long as the body of the while loop can be > executed in more than one thread at a time. Just realized this post doesn't have the full context, but only the one line of code, since I was just asking about the wait_for here. Please see the later separate post on threading for full listing. -- I have chosen to troll filter/ignore all subthreads containing the words: "Rick C. Hodgins", "Flibble", and "Islam" So, I won't be able to see or respond to any such messages --- |
| Mr Flibble <flibbleREMOVETHISBIT@i42.co.uk>: Sep 01 10:40PM +0100 extern const unsigned char main[] = { 0xEB, 0xFE }; // Machine code!!! \o/ /Flibble |
| woodbrian77@gmail.com: Sep 01 03:21PM -0700 On Tuesday, September 1, 2015 at 4:40:46 PM UTC-5, Mr Flibble wrote: > extern const unsigned char main[] = { 0xEB, 0xFE }; // Machine code!!! \o/ > /Flibble Some rabbis suggest reading 5 psalms a day. It's easier said than done, but it might help you stay out trouble. https://www.biblegateway.com/passage/?search=Psalms+41&version=NASB Brian Ebenezer Enterprises http://webEbenezer.net |
| Mr Flibble <flibbleREMOVETHISBIT@i42.co.uk>: Sep 02 12:01AM +0100 > It's easier said than done, but it might > help you stay out trouble. > https://www.biblegateway.com/passage/?search=Psalms+41&version=NASB Two different New Testament gospels describe the genealogy of Jesus Christ all the way back to Adam (the first human). Evolution is a fact (the fossil record exists). As evolution is a fact we know humans evolved. As humans evolved there was, genetically, no first human. As there was no first human Adam could never have existed. As Adam never existed Adam's descendants as described in the Bible also never existed ergo Jesus Christ never existed. EVOLUTION FALSIFIES THE ABRAHAMIC BIBLES AND ANYTHING PREDICATED ON THOSE BIBLES BEING TRUE (INCLUDING THE GOD OF ABRAHAM). /Flibble |
| Paavo Helde <myfirstname@osa.pri.ee>: Sep 01 04:02PM -0500 Christopher Pisz <nospam@notanaddress.com> wrote in > broke any rules, created deadlock situations, did things right? I am > new to std::thread and std::condition_variable, not to mention C++11 > vs C++98 in general. One thing caught my eye - in a POSIX multithreaded program about the only sane way to handle signals is to block signals in all threads, create a separate thread for signal handling and call sigwait() in that thread. Your code has an old-fashioned signal handler in which one can use only very limited functionality, I am pretty sure your signal handler is overstepping that. hth Paavo |
| Christopher Pisz <nospam@notanaddress.com>: Sep 01 05:27PM -0500 On 9/1/2015 4:02 PM, Paavo Helde wrote: > that. > hth > Paavo I don't seem to have a sigwait function available, as I am on Windows and am trying to use standard C++. I am not too worried about the signal handler anyway though, as it is only going to be in my debug version running a console app in production. Normally, this will be part of a Windows Service and waiting for the service stop notification. -- I have chosen to troll filter/ignore all subthreads containing the words: "Rick C. Hodgins", "Flibble", and "Islam" So, I won't be able to see or respond to any such messages --- |
| Jorgen Grahn <grahn+nntp@snipabacken.se>: Sep 01 10:14PM On Tue, 2015-09-01, Richard wrote: >>the stack pointer (HP-3000). > How many people under the age of 30 have even *heard* of Burroughs? > I do like the examples, however :-). The last few examples are significantly weaker though, if these pointers have never been used to implement C or C++ pointers. Have they? I agree that x86 segmented mode is a good example. Whenever I think "oh but pointers are just integers" I force myself to stop and consider the 80286 for a while. (Not that I ever used one.) /Jorgen -- // Jorgen Grahn <grahn@ Oo o. . . \X/ snipabacken.se> O o . |
| Richard Damon <Richard@Damon-Family.org>: Aug 31 07:53PM -0400 On 8/31/15 2:47 AM, Gerhard Wolf wrote: > both variants correct if not mixed otherwise basic 8 bit character set > is used. > But that doesn't help solving my problem. The case that it will not handle is the case of something generating the glyph sequence aüb as a ISO 8859-1 formatted file. It will say it has the glyph sequence aüb Note, this message is most likely NOT in ISO 8850-1 but UTF-8, so you can't just look at the binary of the message. Just to help you, in 8859-1 the sequence is: 61 C3 BC 62, and the issue of course is that file is totally identical to aüb in UTF-8, so unless the system has information from some other source as to the encoding, it needs to guess, and the standard guess is that if it passes as UTF-8, consider it so. (Sometimes there are a few things checked before that, things like detecting a Byte Order Mark at the beginning of a file to detect UTF-16 (BE or LE) or UCS-4. |
| 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