What is the reason to restrict IRQL at which functions like
RtlCompareUnicodeString, etc. can be accessed strictly to PASSIVE_LEVEL?
How safe would it be to access them at APC level? (I know, docs say
“passive”, but docs also don’t say mutexes are SMP-sync applicable) 
Basically, actual problem that I have is that I have a lookup table in a
performance-sensitive path so I want use fast mutexes instead of regular
mutexes (much faster). But fast mutexes rise IRQL to APC which makes it
“illegal” to use Rtl-Unicode functions.
TIA,
Vladimir
You should probably be ok. The main reason for the IRQL restriction on many
Unicode functions are the tables that drive them are paged.
Don Burn (MVP, Windows DDK)
Windows 2k/XP/2k3 Filesystem and Driver Consulting
----- Original Message -----
From: “Vladimir Chtchetkine”
To: “Windows System Software Devs Interest List”
Sent: Thursday, November 06, 2003 6:43 PM
Subject: [ntdev] RtXxxlUnicodeXxxx and IRQL
What is the reason to restrict IRQL at which functions like
RtlCompareUnicodeString, etc. can be accessed strictly to PASSIVE_LEVEL?
How safe would it be to access them at APC level? (I know, docs say
“passive”, but docs also don’t say mutexes are SMP-sync applicable)
Basically, actual problem that I have is that I have a lookup table in a
performance-sensitive path so I want use fast mutexes instead of regular
mutexes (much faster). But fast mutexes rise IRQL to APC which makes it
“illegal” to use Rtl-Unicode functions.
TIA,
Vladimir
—
Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256
You are currently subscribed to ntdev as: xxxxx@acm.org
To unsubscribe send a blank email to xxxxx@lists.osr.com
But how disabling APC may affect them? Well, there will be a page fault
that will turn into paged I/O read that must be completed within calling
thread which means that I/O Mgr will go “simple way” for I/O completion,
without having to schedule completion APC so disabled APC shouldn’t be
an issue… Am I wrong or there is something else into that picture?
-----Original Message-----
From: Don Burn [mailto:xxxxx@acm.org]
Sent: Thursday, November 06, 2003 4:00 PM
To: Windows System Software Devs Interest List
Subject: [ntdev] Re: RtXxxlUnicodeXxxx and IRQL
You should probably be ok. The main reason for the IRQL restriction on
many
Unicode functions are the tables that drive them are paged.
Don Burn (MVP, Windows DDK)
Windows 2k/XP/2k3 Filesystem and Driver Consulting
----- Original Message -----
From: “Vladimir Chtchetkine”
To: “Windows System Software Devs Interest List”
Sent: Thursday, November 06, 2003 6:43 PM
Subject: [ntdev] RtXxxlUnicodeXxxx and IRQL
What is the reason to restrict IRQL at which functions like
RtlCompareUnicodeString, etc. can be accessed strictly to PASSIVE_LEVEL?
How safe would it be to access them at APC level? (I know, docs say
“passive”, but docs also don’t say mutexes are SMP-sync applicable)
Basically, actual problem that I have is that I have a lookup table in a
performance-sensitive path so I want use fast mutexes instead of regular
mutexes (much faster). But fast mutexes rise IRQL to APC which makes it
“illegal” to use Rtl-Unicode functions.
TIA,
Vladimir
—
Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256
You are currently subscribed to ntdev as: xxxxx@acm.org
To unsubscribe send a blank email to xxxxx@lists.osr.com
—
Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256
You are currently subscribed to ntdev as:
xxxxx@borland.com
To unsubscribe send a blank email to xxxxx@lists.osr.com