AMDG Rene Rivera <grafikrobot <at> gmail.com> writes:
struct tag { boost::mutex lock; };
tag tag_;
void f(int (&array)[100][3], unsigned key_index) { assert(key_index < 3); boost::mutex::scoped_lock l(tag_.lock); std::qsort(array,100,sizeof(int[3]), make_c_function<tag,void(const void*,const void*)>( ll::static_cast_≤const int*>(_1)[key_index] < ll::static_cast_≤const int*>(_1)[key_index])); }
Not that the use case makes any sense to me So I'm still guessing as to what you want to achieve with thread safety here.
That's basically what I said needs to be done: retain the lock until you are done with the function. The critical section is now way bigger than I would like. The only way I know to avoid this is to create a fixed pool of functions and have an additional routine that releases a function pointer so that it can be safely reused. struct tag {}; void f(int (&array)[100][3], unsigned key_index) { assert(key_index < 3); void (*f)(const void*,const void*) = make_c_function<tag,void(const void*,const void*)>( ll::static_cast_<const int*>(_1)[key_index] < ll::static_cast_<const int*>(_1)[key_index]); std::qsort(array,100,sizeof(int[3]),f); release_c_function<tag>(f); } If I ever use make_c_function it would probably be in some use like this (to circumvent the fact that a function pointer cannot have data associated) rather than for callacks that are created once and never changed (such as for ios_base::register_callback) In Christ, Steven Watanabe