AutoResetEvents a limited resource?

  • Thread starter Thread starter Guest
  • Start date Start date
G

Guest

Hi All,

In reading the documentation on AutoResetEvents and WaitHandle I'm not sure
whether they are limited resources (i.e. limited by something other than
memory). WaitHandle mentions that it uses some nebulous "operating system
resources" and I would like to know more specifically is happening under the
hood. Is it safe to allocate hundreds of thousands of these things?

--Ben
 
Hi Ben,

An event is considered an operating system resource. Yes, 'physically' it
involves only the memory, but the system keeps a count of allocated
handles - you can see it on the "Perfomance" tab of the Task Manager.
My understanding is the possible number of events to be created depends
totally on the amount of virtual memory available, but still Windows might
maintain some additional tables for housekeeping and this can impose
additional restrictions on the possible number of existing events. At the
moment I am writing this post there is 14960 open handles - this includes
events, mutexes, probably open files and modules, and so on.

Still, why would you need so many events created?
 
I am writing a distributed server application that has a central component
that knows about all connected users (but does not actually host the sessions
itself - it is just a lookup mechanism). That central component needs to
ensure that different components cannot modify the session state at the same
time. I don't want that central component to have to understand all
operations that can happen on a session so I can't use a simple monitor/lock
statement on the central component itself and make the change locally.

I want to be able to lock each user's session independently from a remote
component . A remote component will request the lock, block until timeout or
lock is achieved, make the change to the session, then release the lock.
However, there will be several hundred thousand simultaneous users. So I
want to understand how heavyweight the AutoResetEvents are as I was
considering using them for my blocking mechanism.

--Ben

Dmitriy Lapshin said:
Hi Ben,

An event is considered an operating system resource. Yes, 'physically' it
involves only the memory, but the system keeps a count of allocated
handles - you can see it on the "Perfomance" tab of the Task Manager.
My understanding is the possible number of events to be created depends
totally on the amount of virtual memory available, but still Windows might
maintain some additional tables for housekeeping and this can impose
additional restrictions on the possible number of existing events. At the
moment I am writing this post there is 14960 open handles - this includes
events, mutexes, probably open files and modules, and so on.

Still, why would you need so many events created?

--
Sincerely,
Dmitriy Lapshin [C# / .NET MVP]
Bring the power of unit testing to the VS .NET IDE today!
http://www.x-unity.net/teststudio.aspx

Ben said:
Hi All,

In reading the documentation on AutoResetEvents and WaitHandle I'm not
sure
whether they are limited resources (i.e. limited by something other than
memory). WaitHandle mentions that it uses some nebulous "operating system
resources" and I would like to know more specifically is happening under
the
hood. Is it safe to allocate hundreds of thousands of these things?

--Ben
Click to expand...
Click to expand...
 
I think you can conduct an experiment, creating events one afer another and
testing what is the maximum number possible. I assume you have a very
powerful hardware since you are going to support several hundred thousand
simultaneous users, so I generally think there should be enough RAM
available to allocate all the events.

--
Sincerely,
Dmitriy Lapshin [C# / .NET MVP]
Bring the power of unit testing to the VS .NET IDE today!
http://www.x-unity.net/teststudio.aspx

Ben said:
I am writing a distributed server application that has a central component
that knows about all connected users (but does not actually host the
sessions
itself - it is just a lookup mechanism). That central component needs to
ensure that different components cannot modify the session state at the
same
time. I don't want that central component to have to understand all
operations that can happen on a session so I can't use a simple
monitor/lock
statement on the central component itself and make the change locally.

I want to be able to lock each user's session independently from a remote
component . A remote component will request the lock, block until timeout
or
lock is achieved, make the change to the session, then release the lock.
However, there will be several hundred thousand simultaneous users. So I
want to understand how heavyweight the AutoResetEvents are as I was
considering using them for my blocking mechanism.

--Ben

Dmitriy Lapshin said:
Hi Ben,

An event is considered an operating system resource. Yes, 'physically' it
involves only the memory, but the system keeps a count of allocated
handles - you can see it on the "Perfomance" tab of the Task Manager.
My understanding is the possible number of events to be created depends
totally on the amount of virtual memory available, but still Windows
might
maintain some additional tables for housekeeping and this can impose
additional restrictions on the possible number of existing events. At the
moment I am writing this post there is 14960 open handles - this includes
events, mutexes, probably open files and modules, and so on.

Still, why would you need so many events created?

--
Sincerely,
Dmitriy Lapshin [C# / .NET MVP]
Bring the power of unit testing to the VS .NET IDE today!
http://www.x-unity.net/teststudio.aspx

Ben said:
Hi All,

In reading the documentation on AutoResetEvents and WaitHandle I'm not
sure
whether they are limited resources (i.e. limited by something other
than
memory). WaitHandle mentions that it uses some nebulous "operating
system
resources" and I would like to know more specifically is happening
under
the
hood. Is it safe to allocate hundreds of thousands of these things?

--Ben
Click to expand...
Click to expand...
Click to expand...
 
Back
Top