![]() | |
![]() |
| | Thread Tools | Search this Thread | Display Modes |
#1
| |||
| |||
|
|
There is no way to block kernel APCs from user mode. If you need strict FIFO then I think the easiest approach is to give each thread its own event to wait on. Or may be you can redesign things so that infrequent violations of FIFO order can be handled gracefully. Generally speaking, strict FIFO order is rarely necessary or even desired. For example, critical sections before W2K3 SP1 had scalability problems under contention because they tried to maintain FIFO order (ignoring things like reordering due to kernel APCs). So now critical sections have been changedare no longer -- This posting is provided "AS IS" with no warranties, and confers no rights. "Aleksey Tkachenko" wrote: .NET Mutex are wrappers around OS Mutant ojects so they behave the same, I really don't see how you could prevent the APC's to interfere when you would implement your own FIFO queue. I think about some class, which will include some mutex, event and queue inside. I just was wondering about something the same already included into the dotNET. Or some possibility to block the APC. |
#2
| |||
| |||
|
|
Hit send too early. Anyways, critical sections have been changed in W2K3 SP1 / XP x64 to allow non-FIFO order under contention. |
#3
| |||
| |||
|
|
Hit send too early. Anyways, critical sections have been changed in W2K3 SP1 / XP x64 to allow non-FIFO order under contention. And XP SP2 I thought, or am I wrong? |
#4
| |||
| |||
|
|
"Willy Denoyette [MVP]" wrote: Hit send too early. Anyways, critical sections have been changed in W2K3 SP1 / XP x64 to allow non-FIFO order under contention. And XP SP2 I thought, or am I wrong? No this change is only in W2K3 SP1 (and XP x64 since it's built from the same codebase as server SP1). -- This posting is provided "AS IS" with no warranties, and confers no rights. |
![]() |
| Thread Tools | Search this Thread |
| Display Modes | |
| |