Page 3 of 6
Posted: Tue Nov 06, 2007 4:09 pm
by chrigi
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).
Posted: Tue Nov 06, 2007 7:57 pm
by greenman
x3n wrote:problem:
thread1 starts, locked is false:
switch to thread 2, locked is still false:
and now are both in the critical section.
Hmpf, yes I see ...
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.
Posted: Tue Nov 06, 2007 9:28 pm
by beni
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..
Posted: Tue Nov 06, 2007 10:15 pm
by greenman
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:
Code: Select all
int i=5;
boost::thread thrd1(boost::bind(&write, i));
thrd1.join();
write:
Code: Select all
void write(int &test){
test=10;
return;
}
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
Posted: Wed Nov 07, 2007 9:14 am
by chrigi
beni wrote:Maybe chrigi can help with some past experience..
unfortunately i am busy till 5pm. if you are still at ETH at this time i can visit you
Posted: Wed Nov 07, 2007 10:59 am
by beni
Yeah, why not come by. I don't know if the network guys will still be around, but I'll know what they're up to if not.
Posted: Thu Nov 08, 2007 9:57 am
by patrick
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...
Posted: Thu Nov 08, 2007 10:45 am
by greenman
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
Posted: Thu Nov 08, 2007 11:49 am
by chrigi
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).
Posted: Fri Nov 09, 2007 9:41 am
by patrick
Reducing traffic or calling the network engine more often (higher frequency).
Posted: Sat Nov 10, 2007 9:37 am
by greenman
Hmm... ok
if everything else fails, we'll try it single-threaded but so far I'll try on. Just for the feeling that Orxonox is multithreaded
edit: Another advantage is that connection requests from clients can be handled faster
Posted: Sun Nov 11, 2007 1:09 pm
by patrick
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.
Posted: Sun Nov 11, 2007 4:18 pm
by greenman
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
Posted: Mon Nov 12, 2007 8:24 pm
by x3n
Cool
I can't wait for the first mp-tests
You're doing half of the TIK2 stuff in a few pps-lessons. Impressive.
Posted: Mon Nov 12, 2007 8:29 pm
by beni
It's probably the best preparation for the following two years of computer and network studies.
Hope to see more of this progress.