Friday, July 31, 2015

Digest for comp.lang.c++@googlegroups.com - 13 updates in 3 topics

Doug Mika <dougmmika@gmail.com>: Jul 31 11:15AM -0700

On Thursday, July 30, 2015 at 5:41:32 PM UTC-5, Victor Bazarov wrote:
 
> V
> --
> I do not respond to top-posted replies, please don't ask
 
I'm reading C++ Concurrency in Action: Practical Multithreading by Anthony Williams. Any other you would suggest?
Doug Mika <dougmmika@gmail.com>: Jul 31 11:37AM -0700

On Thursday, July 30, 2015 at 4:59:49 PM UTC-5, Doug Mika wrote:
> ..
> }
 
> in a mutex to ensure that only one thread executes it at a time. Is there another neat/quick way to achieve what I'm trying to do?
 
 
I guess what I wanted to ask is is there a structure/way in C++ to "bundle" commands into "one" command ensuring that once I start executing the first command that no thread will interrupt until I execute the last command in the bundle?
 
ie.
/*beginning of bundle*/
if(!stack.empty()){
/*some code*/
stack.pop();
}
/*end of bundle*/
 
out of the collection of commands I wanted to create "one command" that is guaranteed to be executed without interruptions by ANY other thread?
scott@slp53.sl.home (Scott Lurndal): Jul 31 06:55PM

>}
>/*end of bundle*/
 
>out of the collection of commands I wanted to create "one command" that is guaranteed to be executed without interruptions by ANY other thread?
 
The "proper" way would be for the stack object
to provide thread-safe methods. That means the
stack object needs to handle concurrent access
to the stack internally, using whatever synchronization
mechanism makes sense for the application.
 
The simplest is to use a mutex (e.g. pthread_mutex std::mutex) within
the ::push, ::pop and ::emtpy methods to protect access
to the underlying data structure used to represent a
stack of objects.
 
It's not a good idea to do the synchronization outside of
the stack object.
 
e.g.:
 
void
Stack::push(T& obj)
{
std:lock_guard<std::mutex> lock(_mutex); // _mutex is private class member std::mutex
<push item on stack>
}
 
void
Stack::pop(T& obj)
{
std::lock_guard<std::Mutex> lock(_mutex);
<pop item from stack>
}
Victor Bazarov <v.bazarov@comcast.invalid>: Jul 31 03:10PM -0400

On 7/31/2015 2:15 PM, Doug Mika wrote:
>> --
>> I do not respond to top-posted replies, please don't ask
 
> I'm reading C++ Concurrency in Action: Practical Multithreading by Anthony Williams. Any other you would suggest?
 
It's a good book, I've no doubt.
 
I started learning multithreading while doing it in Java, and for that I
bought "Java Thread Programming" by Paul Hyde (I picked it up in a local
bookstore at the time after browsing for a few minutes). There are
better books out there, probably. There is no single true source of
knowledge, as you are certainly already aware.
 
Right now on my shelf I have also "Patterns for Parallel Programming",
"Parallel Programming with Microsoft Visual C++", "The Art of
Multiprocessor Programming", "Intel Thread Building Blocks" (probably
already obsolete), and "Software Optimization for High Performance
Computing" (from HP Professional Books series). Sadly, I don't get to
open them for what I am doing nowadays...
 
V
--
I do not respond to top-posted replies, please don't ask
Victor Bazarov <v.bazarov@comcast.invalid>: Jul 31 03:12PM -0400

On 7/31/2015 2:37 PM, Doug Mika wrote:
> On Thursday, July 30, 2015 at 4:59:49 PM UTC-5, Doug Mika wrote:
>> [...]
> I guess what I wanted to ask is is there a structure/way in C++ to
"bundle" commands into "one" command ensuring that once I start
executing the first command that no thread will interrupt until I
execute the last command in the bundle?
 
> out of the collection of commands I wanted to create "one command"
> that is guaranteed to be executed without interruptions by ANY other
> thread?
 
See "Critical Section".
 
V
--
I do not respond to top-posted replies, please don't ask
Victor Bazarov <v.bazarov@comcast.invalid>: Jul 31 03:17PM -0400

On 7/31/2015 2:55 PM, Scott Lurndal wrote:
> std::lock_guard<std::Mutex> lock(_mutex);
> <pop item from stack>
> }
 
This is not enough. If the stack reports that it's not empty, then the
code that learned that the stack is not empty starts doing something
hoping that the stack remains non-empty, and another thread pops the
last element from the stack, it can easily interfere with the code that
presumes the stack non-empty until it's time to pop.
 
This is what critical sections are for, IMHO. It's not the best
solution, of course. A better solution would be to refactor the code so
that it doesn't need to keep others from accessing the stack. That's
why I asked Doug about the contents of his ".." in the original post,
but got no answer.
 
V
--
I do not respond to top-posted replies, please don't ask
Christopher Pisz <nospam@notanaddress.com>: Jul 31 02:36PM -0500

On 7/31/2015 2:17 PM, Victor Bazarov wrote:
> why I asked Doug about the contents of his ".." in the original post,
> but got no answer.
 
> V
 
 
I remember running into that. I think we added a lock and unlock to the
interface on top of what was there for such scenarios and would rely on
the internal locks for most things, but lock it externally for things
that would depend on empty or size for logic involving other stack
operations.
 
 
 
--
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
---
scott@slp53.sl.home (Scott Lurndal): Jul 31 08:05PM

>hoping that the stack remains non-empty, and another thread pops the
>last element from the stack, it can easily interfere with the code that
>presumes the stack non-empty until it's time to pop.
 
That's a different mutex. The stack mutex protects the stack.
 
A higher level mutex protects the algorithm that uses the stack.
Doug Mika <dougmmika@gmail.com>: Jul 31 01:41PM -0700

On Thursday, July 30, 2015 at 4:59:49 PM UTC-5, Doug Mika wrote:
> ..
> }
 
> in a mutex to ensure that only one thread executes it at a time. Is there another neat/quick way to achieve what I'm trying to do?
 
.. was to be ANY code you could think of that made sense.
woodbrian77@gmail.com: Jul 30 10:07PM -0700

http://stackoverflow.com/questions/31711261/c-standard-serializtion
 
The OP may find the C++ Middleware Writer to be of interest.
He says he's not interested in JSON or XML.
 
 
Brian
Ebenezer Enterprises - In G-d we trust.
http://webEbenezer.net
"Öö Tiib" <ootiib@hot.ee>: Jul 31 08:45AM -0700

> http://stackoverflow.com/questions/31711261/c-standard-serializtion
 
> The OP may find the C++ Middleware Writer to be of interest.
> He says he's not interested in JSON or XML.
 
Uh? Is it Sabbath so you may not contact him nor ask our
help? I doubt if he wants your tool. He writes that he is
16 years old guy who only recently started with C++ and
is a firm follower of NIH policy.
 
Your tool sort of contradicts with NIH policy.
Perhaps you can help him to write his own
Yet_Another_My_Middleware_Exchange_Rocket.
"R. Schubert" <raphael.schubert@gmx.de>: Jul 31 02:03AM -0700

On Friday, July 31, 2015 at 1:33:26 AM UTC+2, Christopher Pisz wrote:
> words: "Rick C. Hodgins", "Flibble", and "Islam"
> So, I won't be able to see or respond to any such messages
> ---
 
You could do it similarly to the example here
http://en.cppreference.com/w/cpp/locale/ctype
"Öö Tiib" <ootiib@hot.ee>: Jul 31 04:58AM -0700

On Friday, 31 July 2015 02:33:26 UTC+3, Christopher Pisz wrote:
> Is there a way to set the delimeter for an istringstream when using the
> '>> operator'?
 
> I prefer to not use getline if possible.
 
Copy-paste of accepted answer from
 
http://stackoverflow.com/questions/10376199/how-can-i-use-non-default-delimiters-when-reading-a-text-file-with-stdfstream
 
It looks fine.
 
#include <locale>
#include <iostream>
#include <algorithm>
#include <iterator>
#include <vector>
#include <sstream>
 
class my_ctype
: public std::ctype<char>
{
mask my_table[table_size];
public:
my_ctype(size_t refs = 0)
: std::ctype<char>(&my_table[0], false, refs)
{
std::copy_n(classic_table(), table_size, my_table);
my_table['-'] = (mask)space;
my_table['\''] = (mask)space;
}
};
 
// test
int main()
{
std::istringstream input("This is some input from McDonald's and Burger-King.");
std::locale x(std::locale::classic(), new my_ctype);
input.imbue(x);
 
std::copy(std::istream_iterator<std::string>(input),
std::istream_iterator<std::string>(),
std::ostream_iterator<std::string>(std::cout, "\n"));
 
return 0;
}
 
Output:
 
This
is
some
input
from
McDonald
s
and
Burger
King.
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.
Posted by at

No comments:

Post a Comment

Subscribe to: Post Comments (Atom)