Some devices require synchronized access and don't cope with receiving out-of-order packets (#274).

Fixing this will require our drivers to implement some form of locking of the devices, probably cooperative. The most obvious alternative is file locking, but there's the issue of what happens when there are multiple liquidctl instances running with different user privileges.

In this scenario, using $XDG_RUNTIME_DIR (or a reasonable substitute on other platforms) could result in the locks not been honored; a similar problem is already observed in #246. On the other hand, using a common and universally writable location could potentially violate security expectations, particularly when liquidctl and access to the devices is reserved for root/Administrator: for example, an unauthorized processes would be able to DoS liquidctl instances running as root.

Another issue and/or related problem is that, due to specifics of POSIX and other locks, file locking by itself only ensures that different processes are synchronized. And we also need to synchronize any threads of a given process that may try to access a particular device.

Finally, whatever solution is picked, it should try as much as possible to avoid breaking existing workflows that work well. Because of this, it might be reasonable to only implement synchronization for the devices that really need it... where, if necessary, we can argue that the breaking changes were justified to fix a severe bug.

P.S. The issue of devices locking up due to out-of-order packets isn't very common, and we had no (significant) issues until the Platinum/Pro XT coolers. Additionally, in the first versions of liquidctl we mostly used libusb for everything, which required us to claim the particular interface we were going to use, which also ensured exclusive access at the kernel level.