[ros-dev] Race Condition?
ionucu at videotron.ca
Sun Nov 7 19:58:21 CET 2004
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.
> Ros-dev mailing list
> Ros-dev at reactos.com
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).
More information about the Ros-dev