Crystal Space
Welcome, Guest. Please login or register.
October 02, 2014, 03:48:31 pm

Login with username, password and session length
Search:     Advanced search
9020 Posts in 2053 Topics by 8581 Members
Latest Member: Vashikaranmantra33
* Home Help Search Login Register
+  Crystal Space
|-+  Crystal Space Development
| |-+  Support
| | |-+  Multithreading confusion...
« previous next »
Pages: [1] Print
Author Topic: Multithreading confusion...  (Read 1950 times)
maharaja
Jr. Member
**
Posts: 52

t.javed@hotmail.com
View Profile Email
« on: November 23, 2007, 07:51:24 pm »

Hi,

Here is the problem:

If I were coding a single-threaded game only in C++ (not using CS) here is how I'd normally do things in my main loop: read input from keyboard, move things around in the world, draw to the screen.

Thus in a multiplayer game, one could do so: read input from keyboard, read in from network, move things around in world, send messeges back to network, draw on the screen.

But this does not work if you want a fast efficient networking, so the solution is obviously to make it multi-threaded where one thread continuously reads messegaes from network and sends messages out, while another thread moves the things, draws the screen, cook some eggs and whatever...

The question is, since Crystal Space is already multi-threaded, how can one do the above most efficiently?
Should I run multiple threads myself? Or should I do things as if in a single-thread and CS would (somehow) itself take care of multi-threding it?

So for instnace, if I would do all the reading-writing to network inside processframe() how would CS handle it?

Hope I've been able to explain the question and making some sense Smiley

Any help would be greatly appreciated!

/regards
Logged
res
Develazyoper
CS Developer
Full Member
*****
Posts: 206


View Profile Email
« Reply #1 on: November 27, 2007, 06:32:05 pm »

CS won't magically split things into threads for you.

You have to approach it like any other multithreading issue: with synchronization.

Note that you should restrict use of CS to a single thread. (Some interfaces are documented as "thread safe", which is, unfortunately, not entirely true.)
Logged
rvhaasen
Jr. Member
**
Posts: 62


View Profile
« Reply #2 on: November 28, 2007, 05:04:55 pm »

As far as i know cs is -as res already mentioned- single threaded: it is basically a big event dispatcher that distributes events to registered plugins. Processing all events is done by 1 thread. So CS classes are not designed to be thread safe (this would involve embedding expensive synchronisation methods).  Each plugin is however free to use other threads, as long as these threads don't use objects that are used by the main thread (effectively meaning all cs objects) it can do whatever it wants to help speeding up some processing for the plugin.
Communication/synchronisation between the plugin and its thread can be done on many ways, 1 of them is using  message qeues. There are many libraries that abstract this in a platform independent way. I mainly use the opensource Poco library for this.

If you use the RakNet library, most of the processing will already be done by other thread(s) , the API functions (which are "executed" by the main cs thread)  communicate with the network processing thread(s) through message queues, you don't see anything of this from the "outside". As such there is no expensive processing being done by the "main cs thread" (that executes all plugin event handlers).
Logged
Pages: [1] Print 
« previous next »
Jump to:  

Powered by MySQL Powered by PHP Powered by SMF 1.1.2 | SMF © 2006-2007, Simple Machines LLC Valid XHTML 1.0! Valid CSS!
Page created in 7.256 seconds with 15 queries.