Welcome, Guest. Please login or register. Did you miss your activation email?

Author Topic: Semaphores or Conditional Locks  (Read 8022 times)

0 Members and 1 Guest are viewing this topic.

fabianschuiki

  • Newbie
  • *
  • Posts: 2
    • View Profile
Semaphores or Conditional Locks
« on: March 06, 2013, 11:17:18 am »
I stumbled across a common thing in game programming that is not possible to be implemented only using SFML at the moment: job queues creating/holding jobs and worker threads consuming them. In order to do this, the queue needs a semaphore or conditional variable so workers would halt until new jobs become available.

Therefore I think SFML would benefit from an sf::Semaphore and/or sf::ConditionalLock class.

eXpl0it3r

  • SFML Team
  • Hero Member
  • *****
  • Posts: 10777
    • View Profile
    • development blog
    • Email
Re: Semaphores or Conditional Locks
« Reply #1 on: March 06, 2013, 01:23:55 pm »
a common thing in game programming
I'd say this depends highly on the type of game, because simple 2D games mostly never use and neither benefit from multithreading. So I'm not sure how solid a claim for 'commonality' of semaphores and conditional locks in game development is... ;)

Therefore I think SFML would benefit from an sf::Semaphore and/or sf::ConditionalLock class.
SFML is a Simple library and certainly not a concurrency library, thus it's questioning how far it should go. Isn't it possible to implement (at least) semaphores with locks? (I'm not very familiar with conditional locks.)
Besides that the SFML threading part is very limited anyways, thus if one is serious about writing heavily threaded stuff, it might be better to go with std::thread (if supported by the compiler) or boost::thread.

Since I'm curious, for what type of game would you want to see those features? ;)
Official FAQ: https://www.sfml-dev.org/faq.php
Official Discord Server: https://discord.gg/nr4X7Fh
——————————————————————
Dev Blog: https://duerrenberger.dev/blog/

fabianschuiki

  • Newbie
  • *
  • Posts: 2
    • View Profile
Re: Semaphores or Conditional Locks
« Reply #2 on: March 06, 2013, 03:58:36 pm »
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.

JayArby

  • Jr. Member
  • **
  • Posts: 68
    • View Profile
Re: Semaphores or Conditional Locks
« Reply #3 on: April 13, 2013, 06:37:56 am »
SFML is a Simple library and certainly not a concurrency library

What is sf::Thread for, then? ;)

Hiura

  • SFML Team
  • Hero Member
  • *****
  • Posts: 4321
    • View Profile
    • Email
Re: Semaphores or Conditional Locks
« Reply #4 on: April 13, 2013, 10:35:22 am »
What is sf::Thread for, then? ;)

sf::Thread is a **really** minimalist implementation of a thread API. Saying that SFML is a concurrency library because it has this type would be exaggerated.  ;)
SFML / OS X developer

Laurent

  • Administrator
  • Hero Member
  • *****
  • Posts: 32504
    • View Profile
    • SFML's website
    • Email
Re: Semaphores or Conditional Locks
« Reply #5 on: April 13, 2013, 11:47:50 am »
sf::Thread is used by the other modules. Otherwise it wouldn't exist.
Laurent Gomila - SFML developer

Nexus

  • SFML Team
  • Hero Member
  • *****
  • Posts: 6286
  • Thor Developer
    • View Profile
    • Bromeon
Re: Semaphores or Conditional Locks
« Reply #6 on: April 13, 2013, 12:17:44 pm »
You should really have a look at the C++11 standard library. It offers many low-level and high-level threading facilities -- and it's standard.
Zloxx II: action platformer
Thor Library: particle systems, animations, dot products, ...
SFML Game Development:

Tank

  • SFML Team
  • Hero Member
  • *****
  • Posts: 1486
    • View Profile
    • Blog
    • Email
Re: Semaphores or Conditional Locks
« Reply #7 on: April 15, 2013, 10:04:59 am »
I even think that Laurent is going to drop the threading stuff as soon as C++11 will be the primary target. But that's just my assumption.

Laurent

  • Administrator
  • Hero Member
  • *****
  • Posts: 32504
    • View Profile
    • SFML's website
    • Email
Re: Semaphores or Conditional Locks
« Reply #8 on: April 15, 2013, 10:28:44 am »
Quote
I even think that Laurent is going to drop the threading stuff as soon as C++11 will be the primary target.
I will, but dropping pre-C++11 support will not happen in a near future.
Laurent Gomila - SFML developer

Tank

  • SFML Team
  • Hero Member
  • *****
  • Posts: 1486
    • View Profile
    • Blog
    • Email
Re: Semaphores or Conditional Locks
« Reply #9 on: April 15, 2013, 10:33:15 am »
Any specific reason for that?

Laurent

  • Administrator
  • Hero Member
  • *****
  • Posts: 32504
    • View Profile
    • SFML's website
    • Email
Re: Semaphores or Conditional Locks
« Reply #10 on: April 15, 2013, 10:52:04 am »
Because some people are still using old compilers.
« Last Edit: April 15, 2013, 10:59:00 am by Laurent »
Laurent Gomila - SFML developer

Tank

  • SFML Team
  • Hero Member
  • *****
  • Posts: 1486
    • View Profile
    • Blog
    • Email
Re: Semaphores or Conditional Locks
« Reply #11 on: April 15, 2013, 10:56:31 am »
Supporting deprecated/obsolete languages doesn't make the situation better. :)

sebbu

  • Newbie
  • *
  • Posts: 6
    • View Profile
Re: Semaphores or Conditional Locks
« Reply #12 on: April 16, 2013, 10:07:26 am »
Some platform may not have up-to-date compilers (like between gcc 3.4.5 and gcc 4.3 for windows, or any embed architecture).

Laurent

  • Administrator
  • Hero Member
  • *****
  • Posts: 32504
    • View Profile
    • SFML's website
    • Email
Re: Semaphores or Conditional Locks
« Reply #13 on: April 16, 2013, 10:26:56 am »
I don't think it's a priority to hurry and make SFML not work anymore for gcc 3 or VC++ 9 users.
I don't even know if Android and iOS compilers support C++11 properly.

And I wouldn't say that C++03 is deprecated, only 2 years after the new standard was released ;)
Laurent Gomila - SFML developer

Hiura

  • SFML Team
  • Hero Member
  • *****
  • Posts: 4321
    • View Profile
    • Email
Re: Semaphores or Conditional Locks
« Reply #14 on: April 16, 2013, 02:17:13 pm »
Quote
iOS compilers support C++11 properly
Clang does support part of C++11 features. So I would say that iOS support C++11 but I've never tested so... In any case, I also think SFML should not drop C++98/03 so soon.
SFML / OS X developer

 

anything