I read MQX io driver such as uart driver, and find one question.
it seems all driver don't count synchronization between more than one task .
for example, if task A is calling the uart driver's write routine to send some data, but when task A doesn't finish send all data, it is been preempted by task B .
suppose task B also call the driver's write routine, also send some data. then confict occurs. the receiver will get a part of data which is send by task A, and another part of data sent by task B
I am not sure my question is a really trouble
解決済! 解決策の投稿を見る。
Hi Bluehacker,
The drivers are safe but you can have multiple task call the same driver. So the better answer is that the way the drivers are setup is that they are flexible enough to allow multiple task to call them safely but that may not be what you want from a system point of view. If you want more than one task to access the driver and you want them to have synchronization, then you need to implement it using Mutex or Sempahore or global variable.
Hope that helps.
Regards,
David
My question is actually The MQX io driver is thread-safe??
We can call driver in more than one task without synchroniaztion?
Hi Bluehacker,
The drivers are safe but you can have multiple task call the same driver. So the better answer is that the way the drivers are setup is that they are flexible enough to allow multiple task to call them safely but that may not be what you want from a system point of view. If you want more than one task to access the driver and you want them to have synchronization, then you need to implement it using Mutex or Sempahore or global variable.
Hope that helps.
Regards,
David
To answer the OPs question... No you have to do the thread safety yourself.
The MQX I/O subsystem is agnostic regarding renentrancy, leaving thread safety up to the individual drivers. However because MQX does support several priority inversion mitigation techniques you can easily modify the BSP to incorporate semiphores or mutexes in the open, read, write, and ioctl driver interfaces without significantly altering the overall system behavior.
Most of the drivers provided in the example BSPs are not threadsafe - the caveat being they do guard against allowing an open without a close - so if you don't pass the MQX_FILE_PTR to the driver (the return pointer from an fopen) around to multiple threads and make sure to null it when you close a driver you should be fine.