   Multithreading... offering services to other threads?
  I'm trying to design a component-based multithreaded architecture similar to XezekielX's design and the design for Smoke. I'm storing a copy of all object data that a system is interested in in each system (rotation, position, etc) and then synchronizing the data at the end of the frame when all the threads merge together.This design seems like it will work pretty well for what I want, but then I ran into a wall... what if I want a service only a specific system can provide. For instance, if I need a raytrace from something other than the physics system, how can I go about doing that in a thread-safe manner?I came up with two possibilities to answer this question, but I don't really like either one.1. Services are acted upon at the end of the frame during the synchronization step and returned to the requesting system next frame. I don't really like this idea because you might need the results instantly (IE, for raytracing to see if a certain movement is allowed).2. In the case of raytracing, I could have a copy of all the physics data in the calling thread for the service to work off of (since it's using the calling thread's data and not it's own, it would be safe). I don't like this idea because it's unnecessary duplication of data that the calling system shouldn't even really care about...Are there any other ways to solve this problem? Or am I approaching it completely wrong?   
  If you make the data needed by the service read-only, then multiple threads can read from the same instance at the same with no synchronisation issues. This depends a lot on how you structure things, but you can make it so that updates to shared data happen only at the synchronisation point.Personally, I think the "each subsystem in it's own thread" thing is a bit overrated, but that's just me :-)   ;Quote:Original post by Nayruden1. Services are acted upon at the end of the frame during the synchronization step and returned to the requesting system next frame. I don't really like this idea because you might need the results instantly (IE, for raytracing to see if a certain movement is allowed).There's nothing wrong with deferring computation until the next "thread frame" as long as you've got multiple "thread frames" per "graphical frame".e.g. Your renderer might be running at 60Hz, but your threading system might run at 200Hz (or however many cycles are necessary to complete all the computation for one actual frame).As far as the user is concerned (who only sees the 60Hz output), the computation still occurs instantly.Quote:Original post by CodekaPersonally, I think the "each subsystem in it's own thread" thing is a bit overrated, but that's just me :-)At the moment I'm looking into "each subsystem in all threads" - every thread is basically executing the same series of sequential systems (e.g. Input->AI->Physics->Render etc...) but each thread does 1/Nth of the work required by each system.   