You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
We are using ThreadX in combination with FileX, and we are making FileX calls from multiple threads, as FileX is advertised as being thread-safe when used with ThreadX. Recently, we encountered an issue where a call to fx_file_create created a file in the root directory instead of the specified subdirectory, even though the subdirectory did exist.
After an extensive debugging session, we discovered that a race condition between threads was overwriting the path name, leading to the behavior described. Here's how the issue can be reproduced:
Create a subdirectory, for example: /Alarms/
Create a file within that subdirectory: /Alarms/0001_alarm.json
While fx_file_create is searching for an existing file name inside _fx_directory_search, call another FileX function that modifies the media directory name, such as fx_directory_local_path_set.
As a result, the file 0001_alarm.json ends up being created in the root directory instead of /Alarms/.
The race condition is easier to trigger when many files exist in the same directory, since the search takes longer, increasing the likelihood of the conflict. The root of the problem appears to be that FX_PROTECT is called too late. It needs to be invoked at the very beginning—before the media directory entry name is nulled.
I have observed that several other functions may be susceptible to the same behavior. As a temporary workaround, we have wrapped all FileX function calls that are not properly protected with an additional mutex.
Some additional information:
Our logic is functioning correctly—there is no issue in the application code. Additionally, FileX does not return any errors, as we are very meticulous in checking return values. The described behavior only occurs when specific timing conditions between different threads are met.
The text was updated successfully, but these errors were encountered:
Greetings,
We are using ThreadX in combination with FileX, and we are making FileX calls from multiple threads, as FileX is advertised as being thread-safe when used with ThreadX. Recently, we encountered an issue where a call to
fx_file_create
created a file in the root directory instead of the specified subdirectory, even though the subdirectory did exist.After an extensive debugging session, we discovered that a race condition between threads was overwriting the path name, leading to the behavior described. Here's how the issue can be reproduced:
fx_file_create
is searching for an existing file name inside_fx_directory_search
, call another FileX function that modifies the media directory name, such asfx_directory_local_path_set
.The race condition is easier to trigger when many files exist in the same directory, since the search takes longer, increasing the likelihood of the conflict. The root of the problem appears to be that
FX_PROTECT
is called too late. It needs to be invoked at the very beginning—before the media directory entry name is nulled.I have observed that several other functions may be susceptible to the same behavior. As a temporary workaround, we have wrapped all FileX function calls that are not properly protected with an additional mutex.
Some additional information:
Our logic is functioning correctly—there is no issue in the application code. Additionally, FileX does not return any errors, as we are very meticulous in checking return values. The described behavior only occurs when specific timing conditions between different threads are met.
The text was updated successfully, but these errors were encountered: