I would like to know if the feature race conditions is supported by libuci ? in order to manage the access to uci configuration files and synchronized it.
for example : if 2 users make changes at the same time and on the same uci configuration file, the first user makes changes with GUI and the other user makes change with shell.
They're just files and certainly with "shell" access there isn't any notion of "locked for edit". As to the ubus calls, I don't know if they're thread-safe or not, but the same issues with concurrent edit would occur as one process can't "lock" the configuration while changes are being created.
Any time you've got the possibility of concurrent edits in any system, you either need to lock the objects involved at the start of the edit, accept "last one wins", or provide explicit logic to detect and handle the edits in another way. I don't see ubus methods to lock an object or subtree and much of OpenWRT assumes single-user access. I would go under the assumption that there is no explicit protection against concurrent edits. You could always try it on your router to confirm.
I'm not sure of your use case, so I can't comment on how you might accomplish your goals.
The uci library uses flock() to lock configurations it is about to change, apart from that there are no specific concurrency mechanisms.
thanks a lot Jow for your kind information