Ingo Weinhold wrote: > On Wed, 4 May 2005, Stefano Ceccherini wrote: >>>Separating tasks for/in threads makes it easier for the code >to be >>>maintained and >>>enforces the concept of multi-threading, BeOS is very proud >of. >:-) > > Honestly, I can't follow the reasoning. When you serialize tasks by > executing them in one thread instead of executing them in several threads, > using locking where appropriate, how does that further multithreading? It > definitely reduces parallelism. Which is particularly not helpful on SMP > machines. I think you're missing something here... I, we, are trying to serialize _only_ what's needed, the rest should be done in other tasks. I'm trying to separate tasks, not have all sorts of things done from any possible thread. I'm thinking at it as service based architecture - each thread does specific tasks for which it offers services. Why I care so much about this design? Because I want to keep the RootLayer thread (and other threads also) as independent as possible, to have it run continuously, to have regions rebuild as fast as possible. When a thread cannot go further by its own, OK, lock - get your thing done - unlock. BUT, I try to have in that category only getters! If you want to set something, then implement it as a service where its place is. With this design, code flow is a lot more clear, deadlocks are easily avoided and code is very capable on a SMP machine. If I am wrong, please tell me where. I'm _very_ interested in having a _very_ good architecture for our app_server. > A thread should have high priority when it needs to be responsive in > any way, i.e. needs small latencies. Isn't the additional messaging, > counterproductive to that cause? Yes, it is. On a single CPU machine. With SMP it's completely the other way around. But how the future apparently reserves us SMP machines I think we are on the right path. > Anyway, I'll stop discussing at this point. I have no idea what the > RootLayer thread is supposed to do. Implementing it like you did may be > just the best decision, I was just wondering about the reasons. No problem. By raising questions, answers need to be given, and it's always the best answer to be considered. :-) bye, Adi.