Member Avatar for ylchen

Hi all,

I'm looking for a function that releases the CPU for the current executing thread. What I'm doing is implementing a multi-threaded approach to sum table calculations, and using OpenMP for multithreading. Here's the problem:

I have a thread that depends on a number of other threads to finish their calculations (which they'll set a flag). Until then, it just busy-waits polling for the flag. Here's the code snippet for that part (the entire code is a few hundred lines and I'd rather not post that):

while (avail[l1/inc1+1][l2/inc2] == 0
        || avail[l1/inc1][l2/inc2+1] == 0) 
	{
//	printf("Waiting for avail[%d][%d] and [%d][%d]\n", l1/inc1+1,l2/inc2, l1/inc1, l2/inc2+1);
	}

The problem is that when the printf is commented out, the program gets stuck infinite-loop-like behaviour. This infinite loop is not observed when debugged with GDB nor when the printf is uncommented, which makes identifying the problem rather difficult. I'm guessing that it's because the loop is refusing to give up CPU, and by putting a printf it gives up the CPU while waiting for the I/O call to complete, although I don't even see the printf being called sometimes (it seems random depending on which thread the CPU decides to execute first).
Which is the reason why I'm looking for a function call or macro or anything that just releases the CPU for the current thread.
sleep() is too long, I don't want to wait a full millisecond.

environment: Fedora 10, intel cpu

Thanks

  • 2 Contributors
  • 3 Replies
  • 95 Views
  • 12 Hours Discussion Span
  • Latest Post Latest Post by Ancient Dragon

Dani AI

Generated

The observed behavior is a classic visibility/data‑race problem: a tight loop that reads a shared flag without proper synchronization can be optimized or cached by the compiler/CPU so updates from other threads are not seen. I/O calls or running under a debugger often mask the bug because they introduce ordering/visibility side effects. Volatile is not a safe substitute for synchronization; use atomics or proper thread primitives instead (C11 atomics, volatile semantics).

Do not rely on busy-waiting. Replace the flag loop with a synchronization primitive so the waiter actually sleeps and sees updates reliably. On POSIX the standard approach is a condition variable (pthread_cond_wait / pthread_cond_signal) which both yields the CPU and provides the required memory ordering (pthread_cond_wait). If you stay inside OpenMP, use the language synchronization (task dependencies, omp taskwait, omp atomic / omp flush or OpenMP locks) rather than manual polling.

If you only need a short cooperative yield while debugging, use sched_yield() or a very short nanosleep() to give other threads a chance to run — but those do not fix visibility or race conditions (, nanosleep). To find the real bug, run the build under a race detector such as ThreadSanitizer (-fsanitize=thread) or similar tools; they detect missing synchronization far more reliably than eyeballing code (ThreadSanitizer).

Summary for : the printf hiding the bug is a symptom, not a fix. For : sleep/yield can reduce busy CPU use, but correct behavior requires proper synchronization (condition variables, OpenMP synchronization, or C11 atomics).

Recommended Answers

All 3 Replies

Member Avatar for Ancient Dragon

MS-Windows: Sleep(int milliseconds)

*nix: sleep(int seconds) There is another one too that takes milliseconds but I don't recall its name.

In MS-Windows you can call WiatForMultipleObjects() to put the main thread to sleep until all worker threads have finished. You don't need that loop at all.

Edited by Ancient Dragon because: n/a
Member Avatar for ylchen

Thanks for the reply.

Like I said in my original post, sleep() is too long, I don't want to wait a full millisecond. The time I spend sleeping is probably longer than the time I save by multithreading this calculation.
Also, this is a recursive thread-spawning implementation, so the threads that its waiting for does not necessarily finish execution, it just finished that particular part of calculation.

Member Avatar for Ancient Dragon

The subject of this thread is "function to release cpu". Sleep, or a variant, does that. And the cpu can not be release for less than 1 millisecond, and in *nix there is no guarentee that it will be released that length of time.

Be a part of the DaniWeb community

We're a friendly, industry-focused community of developers, IT pros, digital marketers, and technology enthusiasts meeting, networking, learning, and sharing knowledge.