Number of mutex objects a platform can hold

[raulhuertas]

Since mutex objects need some special initialization, I always thought that was a limited number of mutex a processor/platform/OS can hold simultaneously initialized. But I'm exploring a thread-safe scenegraph (NVSG) where all the objects have a mutex, and the API is used something like this:

object.StartEdit();//Mutex locking. The calling thread can edit the data in the object, read and write
(. Edit the object...)
object.EndEdit().//Edit mutex unlock

A scenegraph can hold thousand of objects, so: is there a limit in the number of mutexs a platform can hold simultaneously?

[jimdempseyatthecove]

Quoting - raulhuertas

Since mutex objects need some special initialization, I always thought that was a limited number of mutex a processor/platform/OS can hold simultaneously initialized. But I'm exploring a thread-safe scenegraph (NVSG) where all the objects have a mutex, and the API is used something like this:

object.StartEdit();//Mutex locking. The calling thread can edit the data in the object, read and write
(. Edit the object...)
object.EndEdit().//Edit mutex unlock

A scenegraph can hold thousand of objects, so: is there a limit in the number of mutexs a platform can hold simultaneously?

This is one of those "it depends on definition of mutex" and how you implement it.

When the mutex is an iter-process mutex then the mutex is generally a data object held by the operating system on behalf of the participating processes. In this case the operating system may have a restriction of the numbers of mutex objects (handles to mutex objects).

When the mutex is an intra-process mutex (contained within a singlemulti-threadded process) then the mutex object can be virtually anything you wish.

Taking an off-the-shelf mutex from a library the mutex would typically be one word size (32-bit or 64-bit) but depending on library the mutex may also be one cache line size (64-bytes, 128-bytes,...). These mutex live in the virtual address space of your application. The Virtual Memory limitations of your system would determine the number of mutex you can use.

Rolling your own mutex, you can reduce this to 1 bit and this can be one unused bit in your object protected by the. e.g. lsb of some pointer, or upper bit(s) of a value known to be always 0. In this case, if your system can hold the object, it can also hold the mutex.

(Note in the case of protecting pointer to object the bit can reside in the pointer since usually the 2 lsb bits are available).

Jim Dempsey

[raulhuertas]

Thank you :)