Footprint size of sf::Mutex

[foobarbaz]

Hey all,

I'm working on an implementation of the Entity System design. I'm trying to make it multithreaded - so each system runs in its own thread.

- Systems process entities that have the required components attached to them.
- Components only store data and contain no, or very minimal helper logic.
- Systems running in different threads could access the same entity at the same time, which doesn't end well.

To solve this, I'm thinking I could give each entity instance a mutex, and when a system begins processing the entity, its mutex will lock until the processing is done. My game requires potentially 100k active entities on the client, and around a million on the server.

Is it possible to find out how many bytes an sf::Mutex takes up on each platform?

[eXpl0it3r]

Don't make it multi-threading, especially if you have very little experience with it.
If you lock the entities when they are being used, will in the end create a non parallel game with a huge overhead, due to costant locking and releasing.

The goal of parallel programming is to split the processing into independent tasks, that way they can run in parallel. If you however have complex relations between entities, you'll have to pause one task and wait for another to finish. If the system is really complex you might end up just with one entity being processed at a time, which in turn equals the original system, except that you now how to take care of all the split up, locking, waiting, etc. And then you'd also have to prove that your system can't run into deadlocks or starvation problems.

If you were thinking about write rendering an updating in parallel, you'd have to make sure that all the entities have been processed correctly, otherwise you'd end up with some entities at the old and some at the new position.
And you'd thus lock everything, which will again create a sequential aplication (update() wait() render()).

If you want to write stuff in parallel, you should lear the details first, then implement the game sequentially and at the end let some tasks run in parallel to optimize.

[AlexAUT]

Is it possible to find out how many bytes an sf::Mutex takes up on each platform?

On Unix systems sf::Mutex contains a pthread_mutex_t object which size should be 40bytes.
On win32 systems it contain a CRITICAL_SECTION object which has 24bytes.


AlexAUT

[foobarbaz]

Is it possible to find out how many bytes an sf::Mutex takes up on each platform?

On Unix systems sf::Mutex contains a pthread_mutex_t object which size should be 40bytes.
On win32 systems it contain a CRITICAL_SECTION object which has 24bytes.


AlexAUT

Derp. Thanks!

Don't make it multi-threading, especially if you have very little experience with it.
If you lock the entities when they are being used, will in the end create a non parallel game with a huge overhead, due to costant locking and releasing.

The goal of parallel programming is to split the processing into independent tasks, that way they can run in parallel. If you however have complex relations between entities, you'll have to pause one task and wait for another to finish. If the system is really complex you might end up just with one entity being processed at a time, which in turn equals the original system, except that you now how to take care of all the split up, locking, waiting, etc. And then you'd also have to prove that your system can't run into deadlocks or starvation problems.

If you were thinking about write rendering an updating in parallel, you'd have to make sure that all the entities have been processed correctly, otherwise you'd end up with some entities at the old and some at the new position.
And you'd thus lock everything, which will again create a sequential aplication (update() wait() render()).

If you want to write stuff in parallel, you should lear the details first, then implement the game sequentially and at the end let some tasks run in parallel to optimize.

With so many entities, it is highly unlikely that the same entity will be processed by multiple systems at any given time. Since all logic goes in systems, and systems can only communicate via thread-safe events, I think it might be feasible.

Given that 1 million windows CRITICAL_SECTIONs lock and unlock operations takes only 23.5 nanoseconds, I think the mutex overhead will be negligible. http://preshing.com/20111124/always-use-a-lightweight-mutex/

And finally, I'm just experimenting, having fun, and learning. Besides, someone has to at least attempt it

[Omega]

Is it possible to find out how many bytes an sf::Mutex takes up on each platform?

On Unix systems sf::Mutex contains a pthread_mutex_t object which size should be 40bytes.
On win32 systems it contain a CRITICAL_SECTION object which has 24bytes.


AlexAUT

On Windows, CRITICAL_SECTION may or may not be larger than 24 bytes since it has several pointers to other structures (one of them I looked at being at least 32 bytes) and handles. I'm not sure if the object that a pointer points to counts in the size factor, though.

With so many entities, it is highly unlikely that the same entity will be processed by multiple systems at any given time. Since all logic goes in systems, and systems can only communicate via thread-safe events, I think it might be feasible.

Given that 1 million windows CRITICAL_SECTIONs lock and unlock operations takes only 23.5 nanoseconds, I think the mutex overhead will be negligible. http://preshing.com/20111124/always-use-a-lightweight-mutex/

And finally, I'm just experimenting, having fun, and learning. Besides, someone has to at least attempt it

I honestly don't understand what the point of using 1 million mutexes could solve. If you're going to have 1 million entities as a shared resource, and assuming they're all in a vector or some container for processing by iteration, when the system goes to process the shared resource, just lock down the vector with a single mutex, process, then unlock that one mutex.

[eXpl0it3r]

With so many entities, it is highly unlikely that the same entity will be processed by multiple systems at any given time. Since all logic goes in systems, and systems can only communicate via thread-safe events, I think it might be feasible.

Well it's your time and your headaches, I'm just saying the chance of gain in performance does not justify the amount of work needed.
Good luck anyways!

[Grimshaw]

Not speaking for or against what the OP wants to do, but chances are your game can run in a single thread, and if that is the case, its pointless to do multithreading, as it will provide no benefit(the game already runs smoothly) and any overhead associated with this system will be gratuitous cpu waste.

Just consider if you really need before doing it, is any of the games you're making or want to make that intensive? I can guarantee you that on today's average hardware it is possible to make and run a 3D game considered AAA in a single thread, without problems (excluding async tasks like terrain streaming etc which can only be done in parallel to avoid breaks).

[Jesper Juhl]

Not to mention all the millions of headaches that threading buys you. Like for example (short and incomplete list):
 - data races
 - priority inversions
 - locking overhead
 - deadlocks
 - livelocks
 - crash dumps being meaningless after multiple threads have thrashed the same stack/heap
 - worries over what/how to synchronice what/where/when
 - dealing with non-thread-safe libraries
 - exceptions thrown between threads
 - dealing with multiple processes/threads writing intermixed output to files (file locking)
 - dealing with non-reproducible test results (you are doing TDD I hope)

And a ton of other issues.
If you insist on using threads, at least use standard abstractions like std::async and std::future to lessen the pain.

[Turbine]

When using threads, don't think about locking each kind of resource to allow for mutual access, instead lock behaviours. Start by designing loosely coupled systems which each have a distinguished purpose.

Having too many locks for the most insignificant thing isn't going to benefit you, and will likely cause a lot of problems.

[Lynix]

Given that 1 million windows CRITICAL_SECTIONs lock and unlock operations takes only 23.5 nanoseconds, I think the mutex overhead will be negligible. http://preshing.com/20111124/always-use-a-lightweight-mutex/

As your link points out, 23.5 ns is the lock/unlock time for one critical section.
That makes 23.5ms for one million mutex, which is quite expensive to render a frame in a game.

Edit: Oh wait, this thread is old. Sorry !