X86UNIXSemaphore.cc problem with sem_open on Linux
by Duncan Gray · in Torque Game Engine · 12/04/2004 (6:02 pm) · 8 replies
I don't know if these threads are used anywhere in TGE, I could not find an example. Anyway, I derived a class from Thread ( platformThread.h ) and it crashes at Semaphore::createSemaphore with the sem_open function returning 0 all the time.
I did some "googling" and discovered that this problem with sem_open is fairly common on Linux and some even say it's not supported on Linux.
Can someone enlighten me as to whether it should work or not on RedHat 9 because it does not look likely. Perhaps we should be using pthread_mutex?
I did some "googling" and discovered that this problem with sem_open is fairly common on Linux and some even say it's not supported on Linux.
Can someone enlighten me as to whether it should work or not on RedHat 9 because it does not look likely. Perhaps we should be using pthread_mutex?
About the author
#2
By placing my database calls in threads, I don't get GUI freezes etc. By using a yield in the loop which waits for the server reply there is no noticeable affect on the gameplay when doing a database call mid game.
To use the Thread class, just derive your class from it and overide the "run" method with your own, then call your class methods from within that run method. I just use a switch statement to determine what method to run.
12/05/2004 (10:35 am)
Oh, I also added a yield method to the Thread class (pthread_yield). In case you are wondering why I'm doing all this, I'm using a web based mysql database for a persistant universe and master server. It takes about 1-1.5 seconds to do a send/recv accross the internet with the master in (USA) and the client in (Australia).By placing my database calls in threads, I don't get GUI freezes etc. By using a yield in the loop which waits for the server reply there is no noticeable affect on the gameplay when doing a database call mid game.
To use the Thread class, just derive your class from it and overide the "run" method with your own, then call your class methods from within that run method. I just use a switch statement to determine what method to run.
#3
It would be incredibly good if you were interested in taking the time to make a small tutorial about threads within TGE (use, techniques, reasons why to use, etc.), or possibly a resource of what you're experimenting with for the rest of the community.
12/05/2004 (11:20 am)
While I can't help your issue in any way, I wanted to say thanks for posting what you are learning so far--threaded operations aren't used much at all in the stock code/examples, and it's great to see at least some thoughts on how to set things up--for exactly the reasons you mention!It would be incredibly good if you were interested in taking the time to make a small tutorial about threads within TGE (use, techniques, reasons why to use, etc.), or possibly a resource of what you're experimenting with for the rest of the community.
#4
12/05/2004 (12:44 pm)
Stephen, I will certainly look at doing a tut/resource for using this Thread class as soon as I have finished testing/debugging on both Linux and Windows. I can look at a Mac version if someone wants to donate a Mac.... ;-)
#5
However, it seems WinThread.cc should be changed as below:
bool Thread::join()
{
if(!isAlive())
return(false);
WinThreadData * threadData = reinterpret_cast(mData);
//return(Semaphore::acquireSemaphore(threadData->mSemaphore)); //wrong pointer for join?
return(Semaphore::acquireSemaphore(threadData->threadID));
}
12/05/2004 (5:43 pm)
My Linux version seems to be working fine so far. I have not gone to a windows build yet but just by looking at the info here (MSDN) it seems as if the WinSemaphore.cc Semaphore::acquireSemaphore is correct except perhaps a creatmutex could be used in the createsemaphore function.However, it seems WinThread.cc should be changed as below:
bool Thread::join()
{
if(!isAlive())
return(false);
WinThreadData * threadData = reinterpret_cast
//return(Semaphore::acquireSemaphore(threadData->mSemaphore)); //wrong pointer for join?
return(Semaphore::acquireSemaphore(threadData->threadID));
}
#6
12/06/2004 (11:14 am)
Thing that confuses me here is: why would you ever let a client access a database directly? Client sends to the game server, game server talks to the database server. Any other way and you're asking for trouble.
#7
There several other areas of processing that would benefit from being threaded as well, as in any threaded application!
12/06/2004 (11:31 am)
...who said anything about letting a client access a database directly? For us, abstracting the database calls to their own server is several months later in the dev cycle, mostly due to the cost of another dev platform.There several other areas of processing that would benefit from being threaded as well, as in any threaded application!
#8
The client does not directly contact/login to the database but does it via cgi apps written in C. The cgi apps contain the database passwords etc, the client does not, so there is no way for a hacker to gain access to the database by reverse engineering the client/server or by using a packet sniffer to check the dataflow.
I also use random number handshakes between client/server and cgi app which means you can't even call the cgi app directly via a browser because the handshakes are different every time.
The server also does its own database calls via cgi.
If I really wanted to be paranoid I could use ssl encryption for the database communication but I don't believe it necessary. Maybe later if my game achieves enouch success to attract the interest of hackers/cheats
12/06/2004 (11:44 am)
In my application, due to the nature of the game, the client needs to access the web database before he "joins" or "becomes" a server.The client does not directly contact/login to the database but does it via cgi apps written in C. The cgi apps contain the database passwords etc, the client does not, so there is no way for a hacker to gain access to the database by reverse engineering the client/server or by using a packet sniffer to check the dataflow.
I also use random number handshakes between client/server and cgi app which means you can't even call the cgi app directly via a browser because the handshakes are different every time.
The server also does its own database calls via cgi.
If I really wanted to be paranoid I could use ssl encryption for the database communication but I don't believe it necessary. Maybe later if my game achieves enouch success to attract the interest of hackers/cheats
Torque Owner Duncan Gray
There are a number of other bugs, for instance the join method never calls an actual join on Unix but instead it locks the mutex by calling aquiresemaphore, so I replaced that with pthread_join and took out the aquiresemaphore call.
The Unix createSemaphore function also returns a pointer to a local variable, which obviously gets destroyed when you exit the function ??? Fixed that with new and a delete in the destructor.
The windows version of aquiresemaphore does not aquire anything but instead calls a WaitForSingleObject which will wait for the thread to end ( like a pthread_join) But I'm not a windows thread expert so maybe there is a clever reason why they dont do a mutex_lock type action. Melve?
Warning, I still don't know for sure if this impacts on other areas of TGE thread use. So far, I don't think so because I don't see the Mac versions in the platformMacCarb folder. If thats true then the unix (fixed ) versions should work fine on Mac as well.