True simple 2D games don't use that much multithreading and SFML is supposed to be kept quite simple. But then again, it has implementations of framebuffer objects and *some* threading facilities. Seems to me it's difficult to actually draw a line where the simple stops. One might also argue that complex functionality may be wrapped in a simple interface, thus keeping use of the library simple yet providing powerful features.
I do agree that if SFML intends to keep threading to a minimum, much like a "sneak peak" into multithreading, implementation of advanced syncing mechanisms should be left to other libraries. I had a look at boost and it seems to be more than enough for my use.
Concerning Mutexes: You can have a semaphore mimic a mutex, but a mutex itself cannot act as a semaphore. This is because most mutexes need to be unlocked on the same thread as it was locked. Yet for a producer/consumer threading mechansim, a producing thread must be able to wake a waiting thread, usually by incrementing a semaphore.
I'm programming a small 3D construction game, but I try to make the subsystems highly powerful and optimized.
