network engine
Moderator: PPS-Leaders
I know I am a bit late but I'd like to give some input.
If you need semaphores (for mutual exclusion), sdl can do that job for you (search google for sdl and mutex).
If you really need multi threaded applications, sdl can do that for you SDL_CreateThread...
http://de.wikibooks.org/wiki/SDL:_Threads
You might also consider not using threads (although I don't know what exactly you want to do). Receiving udp non-blocking should not be a problem and for tcp there is select() which knows if a recv/send would block (e.g. if data is available or can be sent).
If you need semaphores (for mutual exclusion), sdl can do that job for you (search google for sdl and mutex).
If you really need multi threaded applications, sdl can do that for you SDL_CreateThread...
http://de.wikibooks.org/wiki/SDL:_Threads
You might also consider not using threads (although I don't know what exactly you want to do). Receiving udp non-blocking should not be a problem and for tcp there is select() which knows if a recv/send would block (e.g. if data is available or can be sent).
Hmpf, yes I see ...x3n wrote:problem:
thread1 starts, locked is false:Code: Select all
locked = false;
switch to thread 2, locked is still false:Code: Select all
readfunction: if(!locked){
and now are both in the critical section.Code: Select all
writefunction: if(!locked){
So I will correct this (would've been too easy )
@chrigi & beni: Thanks for the input but we've considered these before and have taken our decision
boost also provides support for mutex.
I'm not saddle-fast with all those threads and stuff. I also have to use threads in an application I program with a friend and we're not so sure we're doing the right things. Let's look at it tomorrow...
Maybe chrigi can help with some past experience..
Maybe chrigi can help with some past experience..
"I'm Commander Shepard and this is my favorite forum on the internet."
Well, that should be ok now ...
Actually doing this stuff with boost is not that complicated, finding out how it works is something else ... it's not too well documented unfortunately
Just found something out [remark]: You cannot pass &-arguments to a thread-function using bind:
main:
write:
Even after thrd1 was closed i (in main) has still the value 5
Probably boost::bind makes a copy of the argument, which eliminates the speciality of the (int &test).
You got to do this with global variables if i'm not wrong.
edit: Probably a better way is to work with pointers
Actually doing this stuff with boost is not that complicated, finding out how it works is something else ... it's not too well documented unfortunately
Just found something out [remark]: You cannot pass &-arguments to a thread-function using bind:
main:
Code: Select all
int i=5;
boost::thread thrd1(boost::bind(&write, i));
thrd1.join();
Code: Select all
void write(int &test){
test=10;
return;
}
Probably boost::bind makes a copy of the argument, which eliminates the speciality of the (int &test).
You got to do this with global variables if i'm not wrong.
edit: Probably a better way is to work with pointers
I suggest to either not use threads and use the non-blocking network functions (suggestion by chrigi) or to use a real thread library: the boost thread library (suggested by silvan).
Don't think about doing it all yourselfs, it will take you all the time left in this semester to just handle threads...
Don't think about doing it all yourselfs, it will take you all the time left in this semester to just handle threads...
The threads thing should be fine now and the main reason to use threads was not because of the blocking network function (enet uses non-blocking network functions by default).
The reason was to make the delay as small as possible (if the client wants to send something and the server is not in the receiver function then the client would have to wait for the server to be ready to receive (I think this also happens with non-blocking network functions) or the packet would have to be resent later on.
As I already said, threads should be fine now (already tested) and I'll do extensive testing this week with network functions and threads.
cheers
The reason was to make the delay as small as possible (if the client wants to send something and the server is not in the receiver function then the client would have to wait for the server to be ready to receive (I think this also happens with non-blocking network functions) or the packet would have to be resent later on.
As I already said, threads should be fine now (already tested) and I'll do extensive testing this week with network functions and threads.
cheers
As I understand it, the server doesn't have to be in any receiver function. The client can just send whenever he wants and the packets will be queued on the server side until the server calls recv(). Of course packets get lost if the buffer is full but if this happens you should think about reducing the traffic anyway (I am assuming you use udp).
Are there connection requests with the udp protocol (since it's a connection-less network protocol)?
Keep your framework as simple as possible. If you see that a simple solution doesn't fit the requirements, you can always update it to a better and more complex version.
This is neither agains nor pro your multi-threading idea. Just try to make it most fun and satisfying for yourself.
Keep your framework as simple as possible. If you see that a simple solution doesn't fit the requirements, you can always update it to a better and more complex version.
This is neither agains nor pro your multi-threading idea. Just try to make it most fun and satisfying for yourself.
Yep, thats my aim
but I won't just keep it simple because it could be hard otherwise...
Apart from that it's working
Programmed a dummy client and server. The server is multithreaded and uses the packetbuffer and connectionmanager I've written.
On wednesday we will try to integrate the packetgenerator/decoder dumeni's taking care off. Let's hope that this'll be unproblematic.
cheers
but I won't just keep it simple because it could be hard otherwise...
Apart from that it's working
Programmed a dummy client and server. The server is multithreaded and uses the packetbuffer and connectionmanager I've written.
On wednesday we will try to integrate the packetgenerator/decoder dumeni's taking care off. Let's hope that this'll be unproblematic.
cheers
Who is online
Users browsing this forum: No registered users and 1 guest