pausing FunctionA while waiting FunctionB ?

Have function B transmit the result to function A (for instance, by means of a variable shared between the two) then return. Function A's execution will resume eventually, once the library function is done, and it will have the result in the shared variable ready for returning.

Quote:

Original post by ToohrVyk Function A's execution will resume eventually, once the library function is done, and it will have the result in the shared variable ready for returning.

I'm not sure of that, because the extern function call some CUDA stuff, then when this stuff is done, CUDA call function B. So function A will more likely continue the process as return from extern function doesn't imply the result is ready yet.

What ToohrVyk means is that you have a spinlock in FunctionA() to wait that FunctionB() sets the variable, e.g.

static bool is_ready=false;void FunctionB(){  is_ready=true;}void FunctionA(){  is_ready=false;  /*call the external func*/  while(!is_ready)    Sleep(0);}

I like this simple solution. Thanks :)

Note that you can also use a signal and wait on it, if you want to avoid spin-locking and eating 100% of a CPU on waiting. :)

Quote:

Original post by NotAYakk Note that you can also use a signal and wait on it, if you want to avoid spin-locking and eating 100% of a CPU on waiting. :)

Can you be more specific ?

Many threading libraries (e.g. boost) provide a condition variable that will allow you to wait without running burning through CPU cycles.

The code would look something like:

bool done = false;mutex mtx;condition cond;void funcB(){    // ...    scoped_lock lk(mtx);    done = true;    cond.signal();}void funcA(){    external_func();    scoped_lock lk(mtx);    while (!done)        cond.wait(lk); // non-busy wait    // funcB() has finished.}

EDIT: but if external_func() is expected to finish very quickly, you might be better off with a spin lock. Experiment with both methods (assuming you're aiming for speed).

However, simply assigning a value to a bool variable is not a sufficient method for implementing a correct spin lock (in C++ at least). You will need to insert an instruction that propogates the change to all processors. Someone else will have to tell you about the specifics of doing this.

Saying that the bool is volatile is a good place to start. In many C++ compiler environments, that will work. (volatile is intended for "strange memory". It isn't intended for inter-thread communication in C++. But much of the requirements of strange memory and inter-thread communication overlap.)

And yes -- a signal based approach makes the most sense if you expect to be waiting more than 1/30th of a second. Depending on the granularity of your waiting needs, and the degree of real time responsiveness, and where you are in the kernel/user space, different approaches are better than others to this problem.

Quote:

Original post by NotAYakk Saying that the bool is volatile is a good place to start. In many C++ compiler environments, that will work.

I couldn't recommend using volatile with a clear conscience it as won't work in equally many environments, probably more in fact. The semantics change depending merely on the version of the MS compiler you use, for example. It's an incredibly brittle approach.

At the very least, check your compiler docs for the guarantees given and I'd also recommend forcing compilation to fail for any compiler you haven't researched thoroughly.