Subj : Re: Challenge: Multithreading & Synchronization
To   : comp.programming.threads
From : Uenal Mutlu
Date : Fri May 20 2005 04:21 pm

"Maciej Sobczak" wrote
>
> > // case2: shared access to an object:
> > void f()
> > {
> >   for (size_t i = 0; i < vec.size(); i++)
> >     {
> >       Locker L(vec.m);
> >        // manipulate vec
> >     }
> > }

If all modifications to the vector can happen only in this
function then the code is correct. But if additions /deletions
can happen (also) in other functions then it gets hairy.
So, the use of case2 requires that all modifications to an object
happen only in the same one function. Then this case is safe.

> You should stop thinking in terms of separate objects, which you think
> need synchronization. You should synchronize *activities* instead.

I prefer thinking of an individual object and the methods of the object.

> Of course, in *some* cases, the activities will be associated with a
> single object and it is then when it might make sense to tightly
> associate a mutex with a single value object. A queue used between
> threads is a good example, but apart from such specific examples, you
> should synchronize *activities* and you shoule keep *invariants* of your
> program.

In the end you will see that my approach of integrated mutices is the only
clean, flexible, fast, reusable, ...  method for making multithreaded programs ultra-fast.
Just do some more research and then let's talk again about your experience.
Don't blindly believe what some old-schooler's tell you, think yourself  :-)

.