If this is your first visit, be sure to
check out the FAQ by clicking the
link above. You may have to register or Login
before you can post: click the register link above to proceed. To start viewing messages,
select the forum that you want to visit from the selection below.

Re: Context switching and mutex

It depends on what the thread 2 is doing. Mutexes are guards that can help, but it needs all participants to be good citizens i.e. you have to think about what you want to guard as resources. So, in your case, vec seems to be a resource that needs to be shared and hence guarded. Hence, all those participants that need access to this resource SHOULD adhere to rules. In your case, it is insufficient to use a acquire in just thread1, but also in all other threads before they lay hands on vec.

Re: Context switching and mutex

There are two basic approaches do dealing with multi-threading issues.

1) Works by implementation/usage
2) Works by design.

In the first scenario, you use non-thread safe classes, and explicitly code the proper guards around the necessary items

In the second scenarion, you develop robust classes that will give the proper behaviour in all multi-threaded environments.

My experience has been that the first approach is the more common, but is definately mor fragile. It leaves lots of opportunities to miss things in the initial implementation, and for things to break in the face of changes that are unrelated to the actual problem.

The second approach (which I use 90%+ of the time) is to develop classes which are throughly tested to be thread safe. These can then be utilized at the higher levels without having to woory about many of the details.

note: there is actually a third approach which is gaining in popularity, and has some major advantages in multi-processor / multi-core systems (consider the next generation 16,24,32 core systems...). This approach dictates that ALL objects are immutable ALWAYS. An objects state is totally controlled by the constuctor, and NOTHING can change it once it is created.

Since EVERYTHING (except object construction) is read-only, most of the issues simply disappear. And only one thread will be in the process of constructing a specific instance.

This approach requires a MAJOR change in mindset and philosophy, so is normally not viable for existing applications. But the benefits are quite significant!!!

TheCPUWizard is a registered trademark, all rights reserved. (If this post was helpful, please RATE it!) 2008, 2009,2010In theory, there is no difference between theory and practice; in practice there is.

* Join the fight, refuse to respond to posts that contain code outside of [code] ... [/code] tags. See here for instructions
* How NOT to post a question here
* Of course you read this carefully before you posted
* Need homework help? Read this first

Re: Context switching and mutex

Immutability is one of three patterns discussed in the October 2008 MSDN Magazine, for improving thread safety. In the order given in the article, the three patterns are: immutability, purity, isolation.

Unfortunately, the article barely mentions these concepts before concluding.

Re: Context switching and mutex

Originally Posted by MikeAThon

Immutability is one of three patterns discussed in the October 2008 MSDN Magazine, for improving thread safety. In the order given in the article, the three patterns are: immutability, purity, isolation.

Unfortunately, the article barely mentions these concepts before concluding.

That was an excellent article, and one can only hope that is is the first of a series.....

TheCPUWizard is a registered trademark, all rights reserved. (If this post was helpful, please RATE it!) 2008, 2009,2010In theory, there is no difference between theory and practice; in practice there is.

* Join the fight, refuse to respond to posts that contain code outside of [code] ... [/code] tags. See here for instructions
* How NOT to post a question here
* Of course you read this carefully before you posted
* Need homework help? Read this first