IOHIDDeviceSetReport thread safety

Can anyone advice on thread safety of IOHIDDeviceSetReport calls in IOKit framework?

My immediate question here is "what are you actually trying to"? In terms of "basic" thread safety, most IOKit APIs are "thread safe". The user client connection into the kernel and the in kernel driver itself both act as strong serialization points that protect the underlying hardware.

However, most of these APIs are also bound to a particular run loop (see my take on runloops), which means they should really only be called on the same thread that as their run loop. Calling an API like that from a different thread may "work" (in the sense that nothing crashes) but that doesn't necessarily make it a good idea.

Finally, by definition, an API like this is being used to manipulate the state of a physical dece and, presumably, your app would like to have a clear picture of that devices current or expected state... but that's not possible if you're manipulating that state from multiple states.

Any pointers to documentation covering the topic?

HID access itself was documented in "HID Class Device Interface Guide" though you'd probably want to read "Introduction to Accessing Hardware From Applications" as background first. However, I don't think either of them specifically address thread safety, as both largely pre-data GCD (10.6) which is when these threading issues started to become much more complicated.

__
Kevin Elliott
DTS Engineer, CoreOS/Hardware

I have a legacy codebase which sets up a thread and registers IOHIDDevice callbacks with its runloop, but it also does IOHIDDeviceSetReport calls from multiple other threads. From what you wrote my understanding is that it "may work", things will not crash, but in general it is a design to avoid and could cause weird behavior under some circumstances.

I have a legacy codebase which sets up a thread and registers IOHIDDevice callbacks with its runloop, but it also does IOHIDDeviceSetReport calls from multiple other threads. From what you wrote my understanding is that it "may work", things will not crash, but in general it is a design to avoid and could cause weird behavior under some circumstances.

Correct. More specifically, how well it works basically depends entirely on:

• Exactly what you're doing with the accessory.

• How the accessory itself behaves.

In other words, most of the time the issue here isn't "the system failed" but is actually "you broke your accessory".

__
Kevin Elliott
DTS Engineer, CoreOS/Hardware