   MT thinking
  the time for MT has come i''m doing some reading on MT and the basic stuff (like atomic ops and mutex''s) are somewhat clear to me. now, with new knowledge, new questions arise while trying to achive portability for my apps, i have chosen pthreads as my MT lib.1) when designing a class which should be MT safe, all class accessors must have atleast mutex control inside, right?2) but as with many other tehniques, this kinda MT satefy has some overhead.think of this example:we have two threads A and B. each thread handles a number of dynamic objects. for all object''s which are "under" thread A, MT is not needed, but if one object from thread B wants to manipulate data which belongs to a class in thread A, MT is needed.so, it is kinda logically to think about two types of accessors, one "normal" and one MT safe. to get this working, each object also needs an owner ID. so:if(this->ownerID == worker->ownerID)    worker->SetData(666); // normal way, change dataelse    worker->SetDataMT(666);    // MT safe way, init mutex, change data, free mutexof course SetDataMT should indicate if everything went well or not...this good or bad? 
  In general I would not write "thread-safe classes".  I would write normal unsynchronized classes and leave any thread safety concerns up to my caller.  That is, if the caller wants to share an instance of the class amongst several threads then the caller should set up a mutual exclusion device and ensure that all access acquires the correct locks.The reason is that this it''s more versatile; it allows the caller to, for instance, acquire his lock once and perform a series of operations together, and only when they''re all complete release his lock; performing locking within the class would in general prohibit this kind of usage (as each method would acquire the lock, change the state, release the lock). ;  In my opinion, setting an owning thread is actually harmful, as it lulls you into a false sense of security. Even if you set the owner and try to differentiate between owner thread and non-owner thread accesses, it doesn''t matter. Because to be safe, the MT aware function always needs to be called. Otherwise you gain no protection. A call from a non-owning thread while the owning thread is processing a call could still cause data corruption, because the owning thread used no lock.On the whole, making the member functions of an object automatically perform locking doesn''t provide very much safety anyways. Consider, for example, a "thread safe" implementation of std::vector. If we use this code:if (v.size() > 5) v.push_back();It''s true that v.size() will be safe from manipulation from other threads, but the actual size could be different when v.push_back() is called.Even if you decided to not do per-object automatic locking, you do want to consider multithreaded safety when it comes to static class members. Of course the easiest method of doing that is elminating their use. One alternative is using automatic class level locks in certain functions and be very careful of dead lock situations.And good luck. Proper multi-threading programming is a pain in the rear and a half. ;  @DrPizzai c ur point, why protect all functions, when u can protect whole class@sicraneagain, ur right, using MT safe and non MT functions doesnt work...well, my biggest question is how to solve data manipulation from one thread to another... in a perfect world all objects within one thread would not need any objects from other threads, but since this isnt the perfect world :Dthe big part of my objects will be ran via update functions and to keep up a steady rate of updates i need to gruop my objects in diffrent threads. now, if within an update function the object needs to access another object from a diffrent group, i cannot afford to wait for to get free (if it is locked), beacuse that could ruin the update rate. so an idea is to have a sort of a middleman. allthough i hate msg based systems , something like that should be used here. so, when object A needs something from object B (diffrent group), it would send the request to the middleman, which would then notify the caller when the needed resourse is ready. however, if following what drpizza said, the whole object would than again be locked. and what if the time has come for that much needed update call? the object is locked, so the "master" cannot use it... and i''m back at the beggining  ;  I suspect what you''d want to do is to send a message to the thread owning the object and not the object itself. If the message contains sufficient information then the owner thread can do the update itself. ;  There are efforts to implement a very simple to use MT-mechanism for Eiffel:http://www.inf.ethz.ch/personal/meyer/publications/concurrency/scoop_iee.pdfI''d love to see a working implementation of it. ;  after some thinking, i decided that using msg''s instead of MT satefy is not going to be good... so, right now, i''m thinking bout if MT safety should be implemented on a class level like drpizza said or to go with function MT safety. allthough the first option would probably couse less overhead, when using it, the whole object is locked. but if going the second way, the whole object is not locked, only parts of it, so any other functions may still use it... of course standard methods for preventing deadlocks must be used...any comments? ;  Have you read the paper i linked? It describes MT at a higher level of abstraction and in an OO-way.It makes the basic premise that every object is handled (executed) by exactly one thread during it''s whole lifetime and derives some simple rules how correct behaviour can be assured. ;  to be honest, no, i didn''t, i only did a quick flybyone thread for one object? hmm...will read the it asap, i promise ps: now that germany is handball euro champ, u all think ur so smart ;  one more thing:how does mutex "know" what to protect?if i say sothing like this:func(){scoped_mutex a;++data;}how does mutex a "connect" to data? 