Funtionoids, Static Local Variables and Multithreading in C++

[Robertlzw]

I have used Fonctionoids in make functions thread-safe which originally used static local variables in several C++ multhreading projects. Here is the link of my blog on it:
http://zhaowuluo.wordpress.com/category/c-multithreading-3/

Happy reading!

 

[alain]

I don't see the value of this article since he doesn't use it in a multithreaded context. The author is just trying to give you a work around the use of static variables in a multithreaded program without using multiple threads.

It also talks about inline as a guaranteed to increase performance. That's actually not completely true. IIRC from the C++ specification, the inline keyword is used as a request for the compiler to inline functions but that is not guaranteed.

Wikipedia has a good description:

http://en.wikipedia.org/wiki/Inline_function

 

[Robertlzw]

You have to do some homework following my hints. It is not difficult.

"A lot of function calls in software degrades performance. We avoided this. In addition, we inlined the operator()(). Taken together, the functor version of the latter should improve performance." Even your compiler ignores the "inline" hint for the function call operator, the performance can still be improved because "We avoided this (function call)". I do not think you read my blog carefully and fully understand it.

 

[Robertlzw]

To make the threading context clearer, I just added "EDIT" part at the end of my blog. Please read it. You are welcomed to come back with further comments.

 

[Daniel Duffy]

" IIRC from the C++ specification, the inline keyword is used as a request for the compiler to inline functions but that is not guaranteed."

This is correct. It's just a hint to the compiler.. And if the program is running slowly no amount of inlining will help. It is probably not possible to inline code that is more fancy that get() member functions. In that case, _default_ inline does the job as well.

I see 'inline' as being somewhat archaic. Personally, static variable are like global variables in in Cobol. They cause major headaches in multi-threaded and IPC applications. It's kind of asking for trouble.

@Robert,
The word 'Functionoid' is confusing. Do we want more jargon or less? We should not use synonyms for already existing concepts?


So, if the goal is have thread-safe copies of a static variables, why not just use Boost
http://www.boost.org/doc/libs/1_45_...read.thread_local_storage.thread_specific_ptr

In OpenMP we have thread_private.

Or am I missing something? The confusing part for me (maybe for Alain as well) is that the blog discusses performance and thread safety in the space of let's say 30 lines of code.

 

[alain]

So to make things clear, the use of static variables is not seen as good design nowadays and anybody that has done multithreaded code knows that it is the source of headaches.

I still don't see the value in this "functionoid" code. It stills looks like a functor and behaves like a functor. Maybe I'm missing something.

Also, when you said that a lot of function calls degrade performance and that's why you decide to inline a function was true in the past. Modern optimization compilers will inline the functions for you.

BTW, is this "functionoid" term your own creation?

 

[Robertlzw]

The static local variable, "value", in the count() function code is to keep state between function calls. It can not be used in multithreaded programs.

The "Fred" functor and its code does the same job, but with four threads for "counting" from 0 to 99.

I did not invent the word "Functionoid". All answers to the questions from both of you can be found here, especially in its sections "Performance" and "Maintaining state":
http://en.wikipedia.org/wiki/Function_object

You may also read [Stroustrup, C++ 3rd edition, 18.4-last paragraph]:
The key reason this works is that for_each () doesn’t actually assume its third argument to be a function. It simply assumes that its third argument is something that can be called with an appropriate argument. A suitably defined object serves as well as – and often better than – a function. For example, it is easier to inline the application operator of a class than to inline a function passed as a pointer to function. Consequently, function objects often execute faster than do ordinary functions. An object of a class with an application operator (§11.9) is called a functionlike object, a functor, or simply a function object.

 

[Daniel Duffy]

Most people in the C++ community use the name 'function object' and then maybe 'functor' when referring to overloading (). These are well known."Functionoid' sounds a wee bit exotic

BTW will you post the full solution to the exercise?

//
This thread has unfortunately drifted from what should have been a discussion on multithreading to one on basic function objects.

 

[Robertlzw]

What the heck is a functionoid, and why would I use one?
http://www.parashift.com/c++-faq-lite/pointers-to-members.html#faq-33.13

//
my blog mentioned on #1 of this thread explores a technique for C++ multithreading when it comes to deal with static local variable. Unfortunately, its performance (inline) was questioned repeatedly on this thread instead.