Aliberti Emanuele wrote:
Hi Eric
Most of these issues should get fixed by the attached patch. It replaces the hive locks and hive list lock (executive resources) by a global registry lock. The result is that only a single thread can modify the registry.
what is the general criterion (if one exists) one should use when choosing a synchronization object to use in kernel mode code?
I ask you this question, because a possible race condition was reported by Gé in the LPC code. As a preliminary step in fixing that, I introduced a FAST_MUTEX to queue threads that use the LPC facility. Now I see that you use an ERESOURCE to fix the same problem in the CM.
Emanuele _______________________________________________ Ros-dev mailing list Ros-dev@reactos.com http://reactos.com:8080/mailman/listinfo/ros-dev
Hi,
FAST_MUTEX cannot be shared, it's always exclusive, while ERESOURCE can be exclusive or shared. It's usually a waste of resources to use an ERESOURCE if you want the locking to be exclusive, but since we need to support shared access as well, ERESOURCE is a good choice. It's commonly used for Read/Writing to disk (ie, registry).
Best regards, Alex Ionescu