Signaling before waiting on condition variables for the `acl_threadsupport.c` file in the thread support library

[IlanTruanovsky]

With the way it's currently implemented, wouldn't it be possible to call acl_signal_condvar multiple times, incrementing the c->signal_sem semaphore multiple times (i.e. n times), without ever needing to wait for the condvar? If so, that means we can wait for the condvar n times after having called acl_signal_condvar and have it immediately return, since the semaphore's internal count is n. Is this intentional?

[pcolberg]

With the way it's currently implemented, wouldn't it be possible to call acl_signal_condvar multiple times, incrementing the c->signal_sem semaphore multiple times (i.e. n times), without ever needing to wait for the condvar? If so, that means we can wait for the condvar n times after having called acl_signal_condvar and have it immediately return, since the semaphore's internal count is n. Is this intentional?

Excellent question! Yes, your analysis is correct and this is intentional.

acl_signal_condvar() is called by acl_signal_device_update(), which in turn is called by various interrupt signal handlers throughout the runtime that handle kernel or device events. The list of system functions that are safe to call within a signal handler is quite restricted, see signal-safety(7); while sem_post(3) is async-signal-safe, pthread mutex and condition variable functions are not.

fpga-runtime-for-opencl/lib/acl_threadsupport/include/acl_threadsupport/acl_threadsupport.h

Lines 132 to 136 in dd7c2cd

	// - The signal call must be safe to use inside an OS-level signal handler
	// which might be blocking OS signals.
	// So in particular you can't use a pthread_mutex or condition variable
	// for the signal wakeup. The only safe thing to use is sem_post
	// which increments the count on a semaphore.

This should mean that the counter parts calling acl_wait_for_device_update(), e.g., clFlushIntelFPGA() might loop more often than needed. If multiple interrupts are signaled in close succession but processed in a single call to acl_idle_update(), a subsequent call to acl_wait_for_device_update() will return immediately and call acl_idle_update() even though there are no new updates to process. This has no functional impact though since the loop only terminates once, e.g., the queue is empty. So far the theory; I am not sure whether and how often this occurs in practice.

[IlanTruanovsky]

Thank you for answering, @pcolberg!

I'll take a look at the linked code you provided to try and understand this in more depth.

I'll reopen this if I have any more questions.