Shared data: Resource versus fast mutex

NTDEV
1

I have a list of data that can be accessed through various threads - sometimes from a ‘device’, sometimes from a timer and sometimes from usermode. The data is always accessed at PASSIVE IRQL (or I’m in the process of making it that way). As far as usage goes, I’m assuming in most cases the list will contain less than 50 elements.

What are the considerations in using an ERESOURCE versus a FAST_MUTEX?

When there are multiple accessors to data, it seems like it’s always more efficient to use a resource when the access is often read only. But I’d assume that the fast mutex is faster… Does the choice come down to frequency of access?

I’m in the process of using the resources, but find myself wondering if it’s overkill for low frequency access and that it might be more appropriate to simply use the fast mutex.

2

If the target critical section is not that busy fast mutex may be the right solution even for RO access, because on every particular acquisition there is a good chance that the whole thing will involve nothing more than test-and-set. However, don’t forget that, unlike ERESOURCE that can get acquired recursively by its exclusive owner thread, FAST_MUTEX cannot get acquired recursively - any attempt to do so will result in deadlock…

Anton Bassov

3

>What are the considerations in using an ERESOURCE versus a FAST_MUTEX?

Resources are nice in that they’ll increase your parallelism in the mostly
shared case. If you use the FAST_MUTEX you can only have one owner at a
time, so your readers will be exclusive to each other. If you’re really
wailing this for read access data you’ll quickly find this to be a
bottleneck.

Resources have the downside though of being rather heavyweight (there is a
cost in tracking all of that pretty debug information that you can extract
with !locks).

A push lock might be something to look into if you can deal with the O/S
restrictions and the fact that they’re really only documented for use in
mini-filters. Push locks have r/w semantics like resources but aren’t as
easy to debug. See FltInitializePushLock docs for more details.

Even better would be if your driver processing allows for using sequenced
singly linked lists. It’s effectively lock free:

http://msdn.microsoft.com/en-us/library/ff563802(VS.85).aspx#sequenced_singly_linked_lists

Though again that assume that your code can be structured to work within the
confines.

-scott

Scott Noone
Consulting Associate
OSR Open Systems Resources, Inc.
http://www.osronline.com

wrote in message news:xxxxx@ntdev…

I have a list of data that can be accessed through various threads -
sometimes from a ‘device’, sometimes from a timer and sometimes from
usermode. The data is always accessed at PASSIVE IRQL (or I’m in the
process of making it that way). As far as usage goes, I’m assuming in most
cases the list will contain less than 50 elements.

What are the considerations in using an ERESOURCE versus a FAST_MUTEX?

When there are multiple accessors to data, it seems like it’s always more
efficient to use a resource when the access is often read only. But I’d
assume that the fast mutex is faster… Does the choice come down to
frequency of access?

I’m in the process of using the resources, but find myself wondering if it’s
overkill for low frequency access and that it might be more appropriate to
simply use the fast mutex.