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

Author Topic: Continuous Threads Self-Locking or Waiting for Events (Instead of Polling)?  (Read 2671 times)

0 Members and 1 Guest are viewing this topic.

7krs

  • Newbie
  • *
  • Posts: 39
    • View Profile
    • Email
Hello,

I am wondering if (possibly how) it would be possible to utilize sf::Event / (sf::Lock || sf::Mutex) to make threads process data at specific intervals. Why? Because it seems to me that sf::RenderWindow::waitEvent() and the mutexes are able to hlt (0xF4) the thread. This means ~0 processor usage - less power, less heat, more for other purposes.

I came up with two possible methods, but none work:

1. I am unable to lock a thread from itself.
#include <SFML/System.hpp>
#include <iostream>

sf::Mutex mutex;
bool runThread = true;
signed int dataToProcess = 0;

void processData()
{
    while (runThread)
    {
        mutex.lock();
        mutex.lock(); // Here I would like the thread to lock itself, and thus wait for any external mutex.unlock to complete one iteration.
        dataToProcess *= 10;
        std::cout << dataToProcess << std::endl;
    }
}

int main()
{
    sf::Thread dataProcessor(processData);
    dataProcessor.launch();
    while (runThread)
    {
        int numberAddition = 0;
        std::cin >> numberAddition;
        if (numberAddition == 0)
        {
            runThread = false;
            dataProcess.wait();
            return dataToProcess;
        }
        dataToProcess += numberAddition;
        mutex.unlock(); // The thread is now iterated through once.
    }
    return 0;
}

 

2. I am unable to wait for specific events in another thread.
    - Thread_1 & Thread_2 are running in parallel.
    - I want to make Thread_2 wait for a boolean to change. No polling.
    - If said boolean is changed, iterate over Thread_2's instructions.
    - When iteration is complete, wait for a change in boolean again.

This can however be solved by simply launching the thread from the location where it is needed, but what if I have local variables in the thread function that need to be re-initialized (extra processing power)? What if the locals need to contain data from previous iterations (A class can solve this tho...)? What if the function contains smaller parts that we can loop through? Using shared booleans in this context would be messy IMHO.

I'll rephrase my question; can we control a thread - that runs continuously - whilst utilizing the anti-power hogging delight of mutexes/locks or waitEvents? (Or is there something superior?)

eXpl0it3r

  • SFML Team
  • Hero Member
  • *****
  • Posts: 10038
    • View Profile
    • development blog
    • Email
I didn't really understand what you want to do exactly.
What is the purpose of the idea you had?

If you just want to take load of the CPU you can simply use window.setFramerateLimit() which will then internally call sf::sleep() (which calls the OS specific thread sleep function) at the given interval and in the time the processor sleeps it gives its used resources free.
Or isn't that what you wanted to do?
Official FAQ: https://www.sfml-dev.org/faq.php
Nightly Builds: https://www.nightlybuilds.ch/
——————————————————————
Dev Blog: https://dev.my-gate.net/
Thor: http://www.bromeon.ch/libraries/thor/

7krs

  • Newbie
  • *
  • Posts: 39
    • View Profile
    • Email
No that is not exactly what I had in mind;

I'd like a thread to be able to wait until there is a state change, then compute. Simply put.

eXpl0it3r

  • SFML Team
  • Hero Member
  • *****
  • Posts: 10038
    • View Profile
    • development blog
    • Email
I see :)
Well concurrency/multithreading is quite a big topic with many possibilities.
I guess you could use a semaphore for this or it might even be possible with just a mutex.
Just google a bit on thos topic and take a look at semaphores. ;)
Official FAQ: https://www.sfml-dev.org/faq.php
Nightly Builds: https://www.nightlybuilds.ch/
——————————————————————
Dev Blog: https://dev.my-gate.net/
Thor: http://www.bromeon.ch/libraries/thor/

7krs

  • Newbie
  • *
  • Posts: 39
    • View Profile
    • Email
Semaphores sound appropriate, after all, there could be a / some threads dedicated to handling locks. I only worry about increased complexity.

I'll check it out and see if I find any good solutions.

Thanks.

Laurent

  • Administrator
  • Hero Member
  • *****
  • Posts: 32504
    • View Profile
    • SFML's website
    • Email
You can do it with mutexes but it will be ugly and inefficient. What you need is a wait condition, which is a synchronization primitive that SFML doesn't provide.
Laurent Gomila - SFML developer