Boost logo

Boost :

From: Steven Watanabe (steven_at_[hidden])
Date: 2007-04-20 20:35:17


Rene Rivera <grafikrobot <at>> 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]);

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

In Christ,
Steven Watanabe

Boost list run by bdawes at, gregod at, cpdaniel at, john at