vlovich/hidapi — comment on commit dc6ca22775e4a8d9249b710a1a86b6df0050f569
File:  line 0
By vlovich:

I'd probably go with the malloc approach instead of locking. My reasoning is:

1) Much simpler & easier to validate; since there's implicitly no race conditions, you don't have to worry about behaviour in multi-threaded scenarios & you have less to test.
2) Contention in multi-threaded scenarios is handled by the OS instead of hidapi allowing for potentially better throughput/latency. Furthermore, you're not holding a lock for the duration of the I/O.
3) Performance of a decent malloc implementation should be faster; lock + i/o + memcpy + unlock vs malloc + i/o + memcpy. A lock isn't held during I/O & malloc is unlikely to actually result in syscalls or any locking.

Also, Window's doesn't use futexes IIRC & critical sections are more lightweight than mutexes.