SFML community forums
Help => General => Topic started by: Contadotempo on October 04, 2010, 01:17:58 am
-
Hello, once again.
Sorry for creating so many threads in a short amount of time but since I'm on a learning phase, I really want to solve my questions.
Is there a way to change the priority of a thread?
I noticed all the threads I create are being executed with "Lowest" priority.
(http://img269.imageshack.us/img269/9191/threading.png)
On the image, the worker thread plays a music, but since it's running on lowest priority, whenever I do something outside of the application (Open browser, open a folder, open a winrar archive, etc...) the music starts slowing down and skipping.
Is there a way to change this? Or should I stop using SFML thread classes?
Thanks in advance.
-
SFML only provides basic threading features, if you need more you should use another, more specific threading library.
-
SFML only provides basic threading features, if you need more you should use another, more specific threading library.
Changing the thread priority is a basic feature, and as you see, it's pretty useful in a multimedia library, which SFML claims to be.
-
SFML is not a threading API, it only provides what it needs internally. If you need threading features please use a threading library, there are tons available.
-
Ah I see. I understand.
Is there any library for threading that you recommend? Just wondering because asking can save hours of research.
Thanks for your help :)
-
boost.thread is going to be part of the next C++ standard, so I guess this is the best choice. Your compiler may even already implement it as std::thread.
-
SFML is not a threading API, it only provides what it needs internally.
So, if it's really intended to be used solely by the library itself, it shouldn't be exposed to the user - all in all, you don't put the internals of your classes in the public section, do you?
Otherwise, if it's really meant to be available to the user, why you're refusing to implement this feature, even though it's literally several lines of code and some users apparently need it, as you see?
Yeah, SFML is not a threading library. And I don't even want it to be. It's a multimedia library, and therefore, if it provides threading support, it'd be nice if it let the user set the priority of the thread, because there are circumstances when one want to run threads with different than default priority in this kind of applications.
About boost.thread... Quite frankly, I think that many developers don't want to depend on boost. It's simply a big mess. Sure, there are other libraries, but still - if SFML let me to change that priority, I wouldn't have to depend upon other stuff (yay, smaller size of my proggy!).
-
Changing the thread priority is a basic feature, and as you see, it's pretty useful in a multimedia library, which SFML claims to be.
Sorry, but I disagree. This is an advance feature. In my opinion the basic is to provide thread with start and stop function. Only the people who want to manage finely their threads, want a feature like that, the rest of us just want to launch a thread function.
Look at the clock class. There is no pause function which seems to be a basic function. I guess, this function is absent for the same reason and I approve it that's why I found SFML really simple to use : few function but the most important.
-
So, if it's really intended to be used solely by the library itself, it shouldn't be exposed to the user - all in all, you don't put the internals of your classes in the public section, do you?
Otherwise, if it's really meant to be available to the user, why you're refusing to implement this feature, even though it's literally several lines of code and some users apparently need it, as you see?
I wish I could get rid of all the stuff in sfml-system -- thread, clock, etc. This has nothing to do with multimedia programming, but unfortunately it's one of the things that you can't avoid, you always need these basic features in this kind of apps.
That's why I provide minimal support for it, but nothing more: SFML should stay focused on multimedia, and not start to become a bloated general purpose system library.
Like I said, I prefer people to use a dedicated library when they have more specific needs, I don't want to reinvent the wheel here.
About boost.thread... Quite frankly, I think that many developers don't want to depend on boost. It's simply a big mess
boost.thread is the next C++ standard, and is already implemented in recent versions of the compilers. I won't fight against that and provide my own threading library.
-
boost.thread is the next C++ standard, and is already implemented in recent versions of the compilers. I won't fight against that and provide my own threading library.
Not exactly true - surely standard library won't bother with portability, as it's often tied to the specific compiler and operating system. Since boost.thread bothers, it depends upon other parts of boost, what makes it just plain bloated. I do care about compile times, what about you?
-
Yeah, I was just talking about the public API, not the private details. Of course using the standard library will be more convenient, as you will have no external dependency. But I don't think that boost.thread depends on many other parts, maybe just some generic configuration headers.
Regarding the compile times, I don't think there's a huge difference, the things that really take a noticeable time to compile are the metaprogramming-based stuff ; boost.thread is not concerned.
-
I'm using boost.thread myself for advanced stuff, it really doesn't matter in compile-time. You can believe me :)
-
Boost.Thread solved my problem as it sets the thread priority to normal by default.
But, imagine I wanted to change it to "High" priority. Not that I'm going to do so, but I'm just curious. I've been reading boost.thread documentation but couldn't find a way to do so, so I did a bit of research and found the function "SetThreadPriority()" but I'm not sure how to use it.
I've tried this:
[...]
thread th1(threadfunction1,n);
SetThreadPriority(th1, HIGH_PRIORITY_CLASS);
[...]
But I get the error: 'SetThreadPriority' : cannot convert parameter 1 from 'boost::thread' to 'HANDLE'.
What am I doing wrong? Should I be doing this, even? Or is there another way to change the priority of a boost.thread rather than using this function?
I know this isn't related to the topic or to SFML but I just wanted to solve this.
Thanks to everyone for your help
I wish I could get rid of all the stuff in sfml-system -- thread, clock, etc. This has nothing to do with multimedia programming, but unfortunately it's one of the things that you can't avoid, you always need these basic features in this kind of apps.
I found those tools to be very useful, makes the librabry a all in one and it definitely helps those who're just starting, like me hehe.
-
SetThreadPriority is a function of the low-level Windows API, it can't be used directly with a boost thread (but you can pass thread.native_handle() or something like this).
Apparently there's no function in the boost.thread API to change a thread's priority, you will have to use the specific OS functions like SetThreadPriority. Anyway, Google gives you more links than you need to solve this problem.
By the way, how did you create your SFML thread? Its priority shouldn't be lowest, it should be normal.
-
I did it like this:
using namespace sf;
using namespace std;
void thread_tester(void *UserData)
{
cout << "Thread 1 is here." << endl;
/*
Generate random numbers
*/
}
int main()
{
Thread th1(&thread_tester);
th1.Launch();
cout << "Main is here." << endl;
return 0;
}
Used MS Visual Studio 2008 to compile
-
Are you sure that this particular piece of code produces the result shown on your screenshot above? I just tried and the SFML thread appears to have a normal priority, as expected.
-
Are you sure that this particular piece of code produces the result shown on your screenshot above? I just tried and the SFML thread appears to have a normal priority, as expected.
It isn't but the process was the same, I'll post the code as soon as I get home since I don't have the project in this computer.
EDIT @ 4:40pm:
In this computer I have Visual Studio 2010 and I tried compiling the code I posted, and apparently I get normal priority as well. At home I compile with VS2008, that's what I used to compile the original code, thus getting the "lowest priority" issue.
Again, when I get home I'll check this. Could the problem be in VS2008?
I should have tested this before asking...
-
Could the problem be in VS2008?
No, I've tested with VS 2008.
-
Oops, I was thinking of the wrong file just then.
This is the original code from the screenshot:
#include <SFML/System.hpp>
#include <SFML/Audio.hpp>
#include <iostream>
#include <time.h>
using namespace sf;
using namespace std;
//Thread 1
void play_main_menu(void *UserData)
{
Music Music;
Music.OpenFromFile("cistern.ogg");
Music.Play();
while (Music.GetStatus() == Music::Playing)
{
sf::Sleep(0.1f);
}
}
//Main function
int main()
{
int geto;
srand(time(NULL));
Clock c1;
Thread th1(&play_main_menu);
th1.Launch();
Sleep(1.f);
while(c1.GetElapsedTime()!=0)
{
geto = rand() % 256;
cout << "Main: Aos " << c1.GetElapsedTime() << " segundos, o programa gerou: " << geto << endl;
Sleep(1.f);
}
return 0;
}
Now if I try to compile it in VS2008 it doesn't make the thread priority "Lowest" like it did before. Now it makes it "Time Critical". There's definitely something wrong with the settings.
When I compile it in VS2010 it sets it to "normal" like it should.
So I know it's not a problem with SFML, but it's on my side.
I'll try reinstalling VS2008.
Thanks for all the help so far!
-
By the way, musics are already threaded, you don't have to play them in separate threads.