STL & multithreading

[Alexander Terekhov]

Re: STL & multithreading


Pete Becker wrote:[color=blue]
>
> Ioannis Vranos wrote:[color=green]
> >
> > My experience is somewhat limited, however what I had in mind as a
> > thread-safe vector for example, is a vector that accessing or modifying
> > one element does not modify the others.[/color]
>
> Yes, certainly.[/color]

Certainly not true. Since when vector< char > equals to
vector< isolated< char > > (for example)?

regards,
alexander.

[Uenal Mutlu]

Re: STL &amp; multithreading

"Ioannis Vranos" wrote[color=blue]
> Axter wrote:
>[color=green]
> > I've tested it with 5 threads trying to access it at the same time, and
> > it works great.
> > However, I have not tested it for performance.[/color]
>
> Generally speaking, with any wrapper class aside, many times multithreading applications
> run with no problem in single-processor systems and show up their problems in systems with
> more than one processor.[/color]

What's the reason?

[Ioannis Vranos]

Re: STL &amp; multithreading

Uenal Mutlu wrote:
[color=blue][color=green]
>>Generally speaking, with any wrapper class aside, many times multithreading applications
>>run with no problem in single-processor systems and show up their problems in systems with
>>more than one processor.[/color]
>
>
> What's the reason?[/color]


Because this is when real multithreading (more than one threads executing at the same
time) takes place. :-)



--
Ioannis Vranos

http://www23.brinkster.com/noicys

[Pete Becker]

Re: STL &amp; multithreading

Uenal Mutlu wrote:[color=blue]
>
> What's the reason?
>[/color]

Timing. On a single processor system one thread runs for a while then
gets pre-empted and another thread starts running. So conflicts between
threads will only show up as a result of the pre-emption. On a
multi-processor system multiple threads run at the same time, so
conflicts between threads can arise at any time.

--

Pete Becker
Dinkumware, Ltd. (http://www.dinkumware.com)

[Axter]

Re: STL &amp; multithreading

Andre Kostur wrote:[color=blue]
> "Axter" <temp@axter.com > wrote in news:1114206648 .687320.109050
> @f14g2000cwb.go oglegroups.com:
>[color=green]
> > Pete Becker wrote:[color=darkred]
> >> Axter wrote:
> >> >
> >> > Try running, and see if you can break the code.
> >>
> >> while (!vec.empty())
> >> vec.pop_back();
> >>
> >> If the code doesn't lock around the entire loop it will break.[/color][/color][/color]
Sooner[color=blue][color=green]
> > or[color=darkred]
> >> later you'll get a thread switch right after the call to empty[/color]
> > returns[color=darkred]
> >> false, and the vector may, in fact, be empty for the call to[/color]
> > pop_back.[color=darkred]
> >>
> >> As Peter said, locking containers doesn't make an application
> >> thread-safe. And once you've added the high-level protection[/color][/color][/color]
that's[color=blue][color=green][color=darkred]
> >> needed to make the application thread-safe, locks in containers[/color][/color][/color]
will[color=blue][color=green][color=darkred]
> >> usually be redundant.
> >>
> >> --
> >>
> >> Pete Becker
> >> Dinkumware, Ltd. (http://www.dinkumware.com)[/color]
> >
> >
> > Please read the entire posted thread. I'm not talking about a[/color][/color]
vector[color=blue][color=green]
> > by itself. You're above code is not using the wrapper class which[/color][/color]
is[color=blue][color=green]
> > what I was referring to in my previous post.
> > I'm talking about an object wrapped in the thread safe wrapper[/color][/color]
class.[color=blue][color=green]
> > See following link:
> > http://code.axter.com/ThreadSafeObject.h
> >
> >[/color]
>
> Yes, he was talking about using your wrapper class. It was simply[/color]
not[color=blue]
> shown in the code example for brevity's sake. So to rephrase:
>
> while (!vec.empty())
> vec.pop_back();
>
> Replace "vec." with "obj->GetLockedObjec t()->". So let's assume we[/color]
start[color=blue]
> with a 1000000 element vector, and we launch 100 threads with the[/color]
above[color=blue]
> code in it to clear out the vector (and for some strange reason we[/color]
don't[color=blue]
> want to just .clear() it...).
>
> Let's continue the example that say we're down to the last element,[/color]
and[color=blue]
> 25 of the threads check vec.empty() and then there's a thread context[/color]
[color=blue]
> switch right after that. The other 75 threads may be just after the
> vec.pop_back(). One of the 75 gets the thread context, checks for
> vec.empty() and then performs the vec.pop_back(), then context[/color]
switch.[color=blue]
> Say the remaining 74 threads are the ones that get the next contexts.[/color]
[color=blue]
> They all test vec.empty(), find the vector empty, and proceed along[/color]
their[color=blue]
> codepath. Finally those first 25 that were sitting just after the
> vec.empty() call get their timeslices. All 25 will attempt a[/color]
pop_back on[color=blue]
> an empty vector. Boom. (OK, Undefined Behaviour)
>
> Translation, your wrapper class does _not_ provide thread safety as a[/color]
[color=blue]
> silver bullet. It _only_ provides thread safety in a single atomic
> operation. As soon as you need multiple operations on the object to
> perform a task, you're implementation risks a context switch between[/color]
the[color=blue]
> two operations where the state of the object may be modified.[/color]

That's incorrect. If you have a better understanding of the wrapper
class, you'll see that you can do the above logic in a thread safe
manner with the wrapper class protecting the object from being access
simultaneously by multiple threads.

If you have to perform several functions who's results depend on each
other, then you can lock access to the object by using a RefLock
variable.

For the duration of the RefLock variable, the object is locked and only
the one thread can access it.
You can then safely do multiple functions who's results depend on each
other, and do it in a thread safe way.
example:

ThreadSafeObjec t<std::vector<i nt> >::RefLock MyLockedVec =
MyRefThreadSafe OjbectTestCase. MyThreadSafeVec torInstance.Get LockedObject();
if (MyLockedVec->size() > 10000 && MyLockedVec->size()&1) //Due odd
numbers
{
MyLockedVec->pop_back();

For a more complex example see following Unit Test class that is able
to perform all above senerios in an thread safe way.

http://code.axter.com/ThreadSafeOjbectTestCase.h

http://code.axter.com/ThreadSafeOjbectTestCase.cpp

The above unit test has 13 threads accessing the same object, and using
the ThreadSafeObjec t class to allow the objects to be access in a
thread safe manner.

This OO approach is safer, and it makes application locks redundant.

[Axter]

Re: STL &amp; multithreading

Pete Becker wrote:[color=blue]
> Axter wrote:[color=green]
> >
> > Container locks do work.
> > If you have a container lock, then that makes the application lock
> > redundant.
> > Using an application lock is more of a procedural based logic
> > mentality.[/color]
>
> Sigh. I gave you an example that doesn't work with container-level
> locks, and an explanation of why it doesn't work. Until you respond[/color]
to[color=blue]
> that example and that explanation there is no point in any further
> discussion.
>
> --
>
> Pete Becker
> Dinkumware, Ltd. (http://www.dinkumware.com)[/color]

Sigh.
Your examples did not use the wrapper class.
And even if it did, the wrapper class can handle logic in which you
need to perform multiple access to the object in a thread safe manner.
All you need to do is create a RefLock object that last the scope of
the reqired lock,
For an example, see following link:

http://code.axter.com/ThreadSafeOjbectTestCase.h

http://code.axter.com/ThreadSafeOjbectTestCase.cpp

http://code.axter.com/ThreadSafeObject.h

The above Unit Test class proves that the ThreadSafeObjec t wrapper
class works.
If you disagree, please post proven tested code, that will show it to
break, and not unproven theories.

[Axter]

Re: STL &amp; multithreading

Pete Becker wrote:[color=blue]
> Ioannis Vranos wrote:[color=green]
> >
> > My experience is somewhat limited, however what I had in mind as a
> > thread-safe vector for example, is a vector that accessing or[/color][/color]
modifying[color=blue][color=green]
> > one element does not modify the others.[/color]
>
> Yes, certainly. Axter's assertion was that STL containers are not
> thread-safe, and that adding his wrapper makes them thread-safe.[/color]
Under[color=blue]
> this criterion, he's wrong about every implementation of STL that I[/color]
know[color=blue]
> of and he's wrong about what his wrapper does.
>
> --
>
> Pete Becker
> Dinkumware, Ltd. (http://www.dinkumware.com)[/color]

Please don't put words into my mouth.
That is not my assertion.
I believe there are some STL implementations that are thread safe, and
some that are not.
My wrapper class can not make an STL class thread safe.
It can make an instance of the STL class thread safe.

It protects the instance of the STL class from being access
simultaneously by multiple threads.
It can not stop the class from trying to access shared objects.
Will continue this in a later thread, with examples.

[Ioannis Vranos]

Re: STL &amp; multithreading

Axter wrote:
[color=blue]
> I believe there are some STL implementations that are thread safe, and
> some that are not.
> My wrapper class can not make an STL class thread safe.
> It can make an instance of the STL class thread safe.[/color]


In general, don't most implementations that support multithreading provide a thread-safe
standard library?

E.g. VC++:

http://msdn.microsoft.com/library/default.asp?url=/library/en-us/vcstdlib/html/vclrfThreadSafetyInStandardCLibrary.asp

So I suppose in most cases such a wrapper isn't much useful. Also this wrapper implies
overhead when used with a thread-safe standard library, in comparison to using the
thread-safe standard library itself.

For example, #pragma omp for of OpenMP standard can't prove useful when used with a
wrapped container.

The only value I can think of such a wrapper class is for multithreading-enabled compilers
that do not provide any multithreading-enabled (=thread safe) standard library. Are there
such cases?


--
Ioannis Vranos

http://www23.brinkster.com/noicys

[Axter]

Re: STL &amp; multithreading

Ioannis Vranos wrote:[color=blue]
> Axter wrote:
>[color=green]
> > I believe there are some STL implementations that are thread safe,[/color][/color]
and[color=blue][color=green]
> > some that are not.
> > My wrapper class can not make an STL class thread safe.
> > It can make an instance of the STL class thread safe.[/color]
>
>
> In general, don't most implementations that support multithreading[/color]
provide a thread-safe[color=blue]
> standard library?
> E.g. VC++:
>[/color]

When you use a thread-safe standard library like VC++, that means the
class itself is thread safe.
That doesn't not mean that an instance of the class is going to be
thread safe.
My wrapper class makes the instance thread safe. It will not, and can
not make the class itself thread safe.
Example:

class I_AM_A_Threadsa feClass
{
public:
I_AM_A_Threadsa feClass(int x):m_x(x){}
I_AM_A_Threadsa feClass(const
I_AM_A_Threadsa feClass&src):m_ x(src.m_x){}
I_AM_A_Threadsa feClass& operator=(const I_AM_A_Threadsa feClass& src)
{
if (&src != this)
{
m_x = src.m_x;
}
return *this;
}
int ThreadSafeFunct ion(){return m_x;}
private:
int m_x;
};
class Not_A_Threadsaf eClass
{
public:
Not_A_Threadsaf eClass(int x):m_x(NotAThre adSafeFunction( x)){}
Not_A_Threadsaf eClass(const
Not_A_Threadsaf eClass&src):m_x (NotAThreadSafe Function(src.m_ x)){}
Not_A_Threadsaf eClass& operator=(const Not_A_Threadsaf eClass& src)
{
if (&src != this)
{
m_x = NotAThreadSafeF unction(src.m_x );
}
return *this;
}
int NotAThreadSafeF unction(int x)
{
static int NotTrheadSafe = 0;
NotTrheadSafe +=x;
return NotTrheadSafe;
}
private:
int m_x;
};

[Uenal Mutlu]

Re: STL &amp; multithreading

"Ioannis Vranos" wrote[color=blue]
> Uenal Mutlu wrote:
>[color=green][color=darkred]
> >>>void ThreadProc()
> >>>{
> >>> #pragma omp for
> >>> for(vector<int> ::size_type i=0; i<vec.size(); ++i)
> >>> vec[i]= i;
> >>>}
> >>>
> >>>Ie. if you are modifying the vector from more than one application thread.
> >>
> >>Well in this case one should acquire the lock inside this function (in a system that
> >>supports lock-based multithreading) .[/color]
> >
> >
> > No :-)
> > Inside the loop is the correct answer :-)[/color]
>
> ?[/color]

Ok, the example code is not well suited for this.
I would recommend to take a look in my TestCase1 posting.
There the locking is done inside the loop (in the thread proc).
By doing so each thread has equal chance to get access to
the object, and the method is simple and "transparen t".
[color=blue][color=green][color=darkred]
> >>Well, if vector is wrapped (although it is thread-safe) with the proposed wrapper, then
> >>when operator[] was used, the wrapper would acquire the lock, making the rest of the
> >>OpenMP created threads to wait (in the best case scenario).[/color][/color][/color]

Sorry, I haven't worked with OpenMP yet, so I cannot comment on this.
[color=blue][color=green]
> > Sorry, no. Yes, the class itself is thread-safe, but using it is not thread-safe
> > per se if used from multiple threads concurrently.[/color]
>
> Why? In VC++:[/color]

Sorry, I really don't understand why this seems to be so hard to understand.
IMO it is so obvious that any object needs to be protected from
being corrupted by multiple threads. This is independent of STL.
It is false believing if some vendors say their STL implementation
is thread-safe. It is nonsense saying. It is obvious that the inner-workings
of each class must be thread safe; they are just meaning that, and this
does mean nearly nothing for practical usage. Nobody but the
programmer knows (has to) where locking is necessary, so the STL
implementer cannot know what my application logic is, therefore
it is useless to know that their STL is thread-safe.

Axter has posted a link to his test application. Therein is an option to
disable his locking mechanism. Ie. using STL directly. But then the
application crashes as expected since there is no thread-safety.
[color=blue]
> http://msdn.microsoft.com/library/de...rdCLibrary.asp[/color]

For example this case:
"For writes to the same object, the object is thread safe for writing from one thread
when no readers on other threads"

It means: you can write only if there is nobody else accessing the object.
In practice all threads try to access it, so the consequence is: not thread safe,
meaning: you need to synchronize access to the object, meaning you need locking.
[color=blue]
> I assume this applies here:
>
> "For writes to different objects of the same class, the object is thread safe for writing:
>
> * From one thread when no readers on other threads.
> * From many threads."[/color]

This is for a class object with other objects in it (not container items).
For example a class with two std::vector objects.
Actually you can forget what MS writes. They are lulling you with nonsense
with such technical sounding, hard-to-understand terms, only to give people
the false illusion of thread-safety.
[color=blue][color=green]
> > You can do on demand locking on element-wise access need.
> > Then each consumer would lock it, access an element or call
> > a single method of the object, and release the lock when
> > the method finishes (all locking & unlocking done automatically),
> > so would the next thread. All threads can access the object in an
> > interlocked fashion. You only need to lock the object inside the
> > loop with each iteration, not outside the loop.[/color]
>
> Yes but the function is performing only this loop and also acquiring and releasing the
> lock is somewhat expensive.[/color]

What other alternative do you have? If you need that multiple threads
have equal access to a shared resource then you need to lock it.
If you lock before the loop then the object is locked until the loop
finishes, and by this all other threads are blocked until the current
lock holder finishes his loop. I would put the lock inside the loop,
so each thread has the chance to continue its job. And by this the
overall performance is IMO better than to block all the other threads.
[color=blue]
> With OpenMP aside, since we modify the entire container it makes more sense to acquire the
> lock before the entire loop execution and release it afterwards (well it always depends on
> context, it is a logical issue in reality).[/color]

Yes, true, it depends on the logical issue.
[color=blue]
> Leaving this aside, given the thread-safety guarantee in the above URL for that compiler,
> why it is not safe to be used by many threads concurrently without a lock, when each
> threads operations do not affect the other threads, when all threads are reading different
> parts of a vector for example? I am talking always about the specific compiler with the
> aforementioned thread-safety guarantee.[/color]

If they read different parts then there should be no problem. But in practice
it is hard to do, ie. you have to use partitioning etc.

[mihai]

Re: STL &amp; multithreading

Very confusing.

So if I want to write a library I must become "paranoiac" and lock
everything or let the user make the correct logical lock for his
application. This applies to STL too; if I must secure my application
then the STL lock is redundant (if it has some). No?

[Uenal Mutlu]

Re: STL &amp; multithreading

"mihai" wrote[color=blue]
> Very confusing.
>
> So if I want to write a library I must become "paranoiac" and lock
> everything or let the user make the correct logical lock for his
> application. This applies to STL too; if I must secure my application
> then the STL lock is redundant (if it has some). No?[/color]

It depends on your project. But generally if there is the possibilty
that your data can be modified by more than one thread at the
same time then you need to take appropiate precautions.

But you can simply say that for your library to work in multithreading
environment the user of the library (the application writer) has to do
appropriate synchronization s by himself. The library writer cannot
solve this for him because it is nearly impossible to know how
his business logic is, ie. which user data need to be protected etc.

Normally it is the application writer who wants to take the benefits
of multithreading, so it is his job to make his app mt-safe.
If he does it well then nearly any library can be used safely.

[Axter]

Re: STL &amp; multithreading

mihai wrote:[color=blue]
> Very confusing.
>
> So if I want to write a library I must become "paranoiac" and lock
> everything or let the user make the correct logical lock for his
> application. This applies to STL too; if I must secure my application
> then the STL lock is redundant (if it has some). No?[/color]

No, it's not redundant.

A few of you are missing the distinction between a thread-safe class
and a thread-safe object.
1. Thread Safe Class
2. Thread Safe Object

Thread Safe Class
Let me try to explain what is a thread safe CLASS, and why it's
needed.
Many of you may already know that most implementations for std::string
use reference counters.
The reference counter can be shared between multiple copies of the same
object.
Example:
string text1 = "Hello World";
string text2 = text1;
string text3(text1);

If you ran the above code, on most implementation you'll find that
all of the above variables are pointing to the same buffer, instead of
each one creating it's own copy of the string.
If you have this type of std::string implementation that is not a
thread safe class, you can run into problems if you passed text1 to
thread1, text2 to thread2 and text3 to thread3.
You can run into problems if these three different threads try to
simultaneously modify these three different strings at the same time,
since they're sharing reference counters and the same data pointer.
So in order to be able to use three DIFFERENT strings in different
threads, the std::string class needs to be thread safe.

Thread Safe Object
Now lets look at a different scenario.
Say you only have ONE object.
string text1 = "Hello World";

Now let say you want to use this single one and only string in three
different threads, and all three threads need to modify the string and
read from it.
In order to do this in a thread safe way, you need to either wrap this
object in a thread safe wrapper, or you need to add code to each thread
so that it creates a lock before accessing the object, and an unlock
when it's done accessing.
In either case, you're adding code that will make the instance of the
class thread safe. You're not making the std::string class itself
thread safe, you're making the usage of text1 thread safe.

So having a thread safe class is not the same as having a thread safe
instance of that class. A thread safe object wrapper class can not do
the job of a thread safe class, and a thread safe class can not do the
job of a thread safe object wrapper class.
These are two different things, and they're not redundant.

Our main debate here is whether it's better to have code for each
thread that would do the lock and unlock synchronization logic, or just
put the object in a wrapper class that would allow the object itself to
be access in a thread safe way.
IMHO, it would require more maintenance to add the code to each thread,
or to add the code in an application level. Also IMHO, this method
would lead to more bugs.

IMHO, by using the Thread Safe Wrapper class you would have less
maintenance and less bugs.

Also by using the wrapper class method, you encapsulate the code that
is being used to lock and unlock the object. That means if you want to
port your code to another platform, all you have to do is modify the
wrapper class, instead of having to modify each thread, or the entire
application base thread logic.

[Ioannis Vranos]

Re: STL &amp; multithreading

Uenal Mutlu wrote:
[color=blue]
> Sorry, I haven't worked with OpenMP yet, so I cannot comment on this.[/color]


http://www.openmp.org. You can download the standard for free.


Upcoming VC++ 2005 supports OpenMP 2 and current Intel C++ compiler supports it too. It is
a multiplatform, portable standard and has not anything to do with application-logic, it
is structure-based.

[color=blue]
> Sorry, I really don't understand why this seems to be so hard to understand.[/color]


Perhaps because I do not know Win32/MFC. But I will provide .NET examples below. :-)


[color=blue]
> For example this case:
> "For writes to the same object, the object is thread safe for writing from one thread
> when no readers on other threads"
>
> It means: you can write only if there is nobody else accessing the object.[/color]


Actually it is case by case. The "From many threads" for writing below is a separate case.
I will provide .NET code demonstrating that below.


[color=blue]
> In practice all threads try to access it, so the consequence is: not thread safe,
> meaning: you need to synchronize access to the object, meaning you need locking.
>
>[color=green]
>>I assume this applies here:
>>
>>"For writes to different objects of the same class, the object is thread safe for writing:
>>
>> * From one thread when no readers on other threads.
>> * From many threads."[/color]
>
>
> This is for a class object with other objects in it (not container items).[/color]


Actually the page mentions containers in the beginning.

[color=blue]
> For example a class with two std::vector objects.
> Actually you can forget what MS writes. They are lulling you with nonsense
> with such technical sounding, hard-to-understand terms, only to give people
> the false illusion of thread-safety.[/color]


Here is .NET code writing to a vector with 5 separate threads. Each thread writes to a
separate block of a vector and no thread-locks are used. The output looks like OK, so the


"For writes to different objects of the same class, the object is thread safe for writing:

* From one thread when no readers on other threads.
==> * From many threads."


looks like it applies here.



#using <mscorlib.dll >

#include <vector>
#include <iostream>


__gc class SomeClass
{
std::vector<int > *pvec;

public:
SomeClass()
{
pvec= new std::vector<int >(1000);
}

~SomeClass()
{
delete pvec;
}

void Write1()
{
for(std::vector <int>::size_typ e i=0; i<200; ++i)
(*pvec)[i]= i;
}

void Write2()
{
for(std::vector <int>::size_typ e i=200; i<400; ++i)
(*pvec)[i]= i;
}

void Write3()
{
for(std::vector <int>::size_typ e i=400; i<600; ++i)
(*pvec)[i]= i;
}

void Write4()
{
for(std::vector <int>::size_typ e i=600; i<800; ++i)
(*pvec)[i]= i;
}

void Write5()
{
for(std::vector <int>::size_typ e i=800; i<1000; ++i)
(*pvec)[i]= i;
}

void DisplayValues()
{
using namespace std;

for(vector<int> ::iterator p= pvec->begin(); p!= pvec->end(); ++p)
cout<<*p<<"\t";
}
};


int main()
{
using namespace System;
using namespace System::Threadi ng;
using namespace std;


SomeClass *pSomeClass= __gc new SomeClass;

Thread *pthread1= __gc new Thread (__gc new ThreadStart(pSo meClass,
&SomeClass::Wri te1) );
Thread *pthread2= __gc new Thread (__gc new ThreadStart(pSo meClass,
&SomeClass::Wri te2) );
Thread *pthread3= __gc new Thread (__gc new ThreadStart(pSo meClass,
&SomeClass::Wri te3) );
Thread *pthread4= __gc new Thread (__gc new ThreadStart(pSo meClass,
&SomeClass::Wri te4) );
Thread *pthread5= __gc new Thread (__gc new ThreadStart(pSo meClass,
&SomeClass::Wri te5) );


pthread1->Start();
pthread2->Start();
pthread3->Start();
pthread4->Start();
pthread5->Start();


// Main thread waits for some time to let the other threads finish
Thread::Sleep(5 000);

pSomeClass->DisplayValues( );
}


C:\c>temp
0 1 2 3 4 5 6 7 8 9
10 11 12 13 14 15 16 17 18 19
20 21 22 23 24 25 26 27 28 29
30 31 32 33 34 35 36 37 38 39
40 41 42 43 44 45 46 47 48 49
50 51 52 53 54 55 56 57 58 59
60 61 62 63 64 65 66 67 68 69
70 71 72 73 74 75 76 77 78 79
80 81 82 83 84 85 86 87 88 89
90 91 92 93 94 95 96 97 98 99
100 101 102 103 104 105 106 107 108 109
110 111 112 113 114 115 116 117 118 119
120 121 122 123 124 125 126 127 128 129
130 131 132 133 134 135 136 137 138 139
140 141 142 143 144 145 146 147 148 149
150 151 152 153 154 155 156 157 158 159
160 161 162 163 164 165 166 167 168 169
170 171 172 173 174 175 176 177 178 179
180 181 182 183 184 185 186 187 188 189
190 191 192 193 194 195 196 197 198 199
200 201 202 203 204 205 206 207 208 209
210 211 212 213 214 215 216 217 218 219
220 221 222 223 224 225 226 227 228 229
230 231 232 233 234 235 236 237 238 239
240 241 242 243 244 245 246 247 248 249
250 251 252 253 254 255 256 257 258 259
260 261 262 263 264 265 266 267 268 269
270 271 272 273 274 275 276 277 278 279
280 281 282 283 284 285 286 287 288 289
290 291 292 293 294 295 296 297 298 299
300 301 302 303 304 305 306 307 308 309
310 311 312 313 314 315 316 317 318 319
320 321 322 323 324 325 326 327 328 329
330 331 332 333 334 335 336 337 338 339
340 341 342 343 344 345 346 347 348 349
350 351 352 353 354 355 356 357 358 359
360 361 362 363 364 365 366 367 368 369
370 371 372 373 374 375 376 377 378 379
380 381 382 383 384 385 386 387 388 389
390 391 392 393 394 395 396 397 398 399
400 401 402 403 404 405 406 407 408 409
410 411 412 413 414 415 416 417 418 419
420 421 422 423 424 425 426 427 428 429
430 431 432 433 434 435 436 437 438 439
440 441 442 443 444 445 446 447 448 449
450 451 452 453 454 455 456 457 458 459
460 461 462 463 464 465 466 467 468 469
470 471 472 473 474 475 476 477 478 479
480 481 482 483 484 485 486 487 488 489
490 491 492 493 494 495 496 497 498 499
500 501 502 503 504 505 506 507 508 509
510 511 512 513 514 515 516 517 518 519
520 521 522 523 524 525 526 527 528 529
530 531 532 533 534 535 536 537 538 539
540 541 542 543 544 545 546 547 548 549
550 551 552 553 554 555 556 557 558 559
560 561 562 563 564 565 566 567 568 569
570 571 572 573 574 575 576 577 578 579
580 581 582 583 584 585 586 587 588 589
590 591 592 593 594 595 596 597 598 599
600 601 602 603 604 605 606 607 608 609
610 611 612 613 614 615 616 617 618 619
620 621 622 623 624 625 626 627 628 629
630 631 632 633 634 635 636 637 638 639
640 641 642 643 644 645 646 647 648 649
650 651 652 653 654 655 656 657 658 659
660 661 662 663 664 665 666 667 668 669
670 671 672 673 674 675 676 677 678 679
680 681 682 683 684 685 686 687 688 689
690 691 692 693 694 695 696 697 698 699
700 701 702 703 704 705 706 707 708 709
710 711 712 713 714 715 716 717 718 719
720 721 722 723 724 725 726 727 728 729
730 731 732 733 734 735 736 737 738 739
740 741 742 743 744 745 746 747 748 749
750 751 752 753 754 755 756 757 758 759
760 761 762 763 764 765 766 767 768 769
770 771 772 773 774 775 776 777 778 779
780 781 782 783 784 785 786 787 788 789
790 791 792 793 794 795 796 797 798 799
800 801 802 803 804 805 806 807 808 809
810 811 812 813 814 815 816 817 818 819
820 821 822 823 824 825 826 827 828 829
830 831 832 833 834 835 836 837 838 839
840 841 842 843 844 845 846 847 848 849
850 851 852 853 854 855 856 857 858 859
860 861 862 863 864 865 866 867 868 869
870 871 872 873 874 875 876 877 878 879
880 881 882 883 884 885 886 887 888 889
890 891 892 893 894 895 896 897 898 899
900 901 902 903 904 905 906 907 908 909
910 911 912 913 914 915 916 917 918 919
920 921 922 923 924 925 926 927 928 929
930 931 932 933 934 935 936 937 938 939
940 941 942 943 944 945 946 947 948 949
950 951 952 953 954 955 956 957 958 959
960 961 962 963 964 965 966 967 968 969
970 971 972 973 974 975 976 977 978 979
980 981 982 983 984 985 986 987 988 989
990 991 992 993 994 995 996 997 998 999

C:\c>


[color=blue]
> What other alternative do you have? If you need that multiple threads
> have equal access to a shared resource then you need to lock it.[/color]


Yes. If it is one object, however the story is different when we are dealing with separate
elements of a container which is our subject (STL).




--
Ioannis Vranos

http://www23.brinkster.com/noicys

[Axter]

Re: STL &amp; multithreading


Ioannis Vranos wrote:[color=blue]
> Uenal Mutlu wrote:
>[color=green]
> > Sorry, I haven't worked with OpenMP yet, so I cannot comment on[/color][/color]
this.[color=blue]
>
>
> http://www.openmp.org. You can download the standard for free.
>
>
> Upcoming VC++ 2005 supports OpenMP 2 and current Intel C++ compiler[/color]
supports it too. It is[color=blue]
> a multiplatform, portable standard and has not anything to do with[/color]
application-logic, it[color=blue]
> is structure-based.
>
>[color=green]
> > Sorry, I really don't understand why this seems to be so hard to[/color][/color]
understand.[color=blue]
>
>
> Perhaps because I do not know Win32/MFC. But I will provide .NET[/color]
examples below. :-)[color=blue]
>
>
>[color=green]
> > For example this case:
> > "For writes to the same object, the object is thread safe for[/color][/color]
writing from one thread[color=blue][color=green]
> > when no readers on other threads"
> >
> > It means: you can write only if there is nobody else accessing the[/color][/color]
object.[color=blue]
>
>
> Actually it is case by case. The "From many threads" for writing[/color]
below is a separate case.[color=blue]
> I will provide .NET code demonstrating that below.
>
>
>[color=green]
> > In practice all threads try to access it, so the consequence is:[/color][/color]
not thread safe,[color=blue][color=green]
> > meaning: you need to synchronize access to the object, meaning you[/color][/color]
need locking.[color=blue][color=green]
> >
> >[color=darkred]
> >>I assume this applies here:
> >>
> >>"For writes to different objects of the same class, the object is[/color][/color][/color]
thread safe for writing:[color=blue][color=green][color=darkred]
> >>
> >> * From one thread when no readers on other threads.
> >> * From many threads."[/color]
> >
> >
> > This is for a class object with other objects in it (not container[/color][/color]
items).[color=blue]
>
>
> Actually the page mentions containers in the beginning.
>
>[color=green]
> > For example a class with two std::vector objects.
> > Actually you can forget what MS writes. They are lulling you with[/color][/color]
nonsense[color=blue][color=green]
> > with such technical sounding, hard-to-understand terms, only to[/color][/color]
give people[color=blue][color=green]
> > the false illusion of thread-safety.[/color]
>
>
> Here is .NET code writing to a vector with 5 separate threads. Each[/color]
thread writes to a[color=blue]
> separate block of a vector and no thread-locks are used. The output[/color]
looks like OK, so the[color=blue]
>
>
> "For writes to different objects of the same class, the object is[/color]
thread safe for writing:[color=blue]
>
> * From one thread when no readers on other threads.
> ==> * From many threads."
>
>
> looks like it applies here.
>
>
>
> #using <mscorlib.dll >
>
> #include <vector>
> #include <iostream>
>
>
> __gc class SomeClass
> {
> std::vector<int > *pvec;
>
> public:
> SomeClass()
> {
> pvec= new std::vector<int >(1000);
> }
>
> ~SomeClass()
> {
> delete pvec;
> }
>
> void Write1()
> {
> for(std::vector <int>::size_typ e i=0; i<200; ++i)
> (*pvec)[i]= i;
> }
>
> void Write2()
> {
> for(std::vector <int>::size_typ e i=200; i<400; ++i)
> (*pvec)[i]= i;
> }
>
> void Write3()
> {
> for(std::vector <int>::size_typ e i=400; i<600; ++i)
> (*pvec)[i]= i;
> }
>
> void Write4()
> {
> for(std::vector <int>::size_typ e i=600; i<800; ++i)
> (*pvec)[i]= i;
> }
>
> void Write5()
> {
> for(std::vector <int>::size_typ e i=800; i<1000; ++i)
> (*pvec)[i]= i;
> }
>
> void DisplayValues()
> {
> using namespace std;
>
> for(vector<int> ::iterator p= pvec->begin(); p!=[/color]
pvec->end(); ++p)[color=blue]
> cout<<*p<<"\t";
> }
> };
>
>
> int main()
> {
> using namespace System;
> using namespace System::Threadi ng;
> using namespace std;
>
>
> SomeClass *pSomeClass= __gc new SomeClass;
>
> Thread *pthread1= __gc new Thread (__gc new[/color]
ThreadStart(pSo meClass,[color=blue]
> &SomeClass::Wri te1) );
> Thread *pthread2= __gc new Thread (__gc new[/color]
ThreadStart(pSo meClass,[color=blue]
> &SomeClass::Wri te2) );
> Thread *pthread3= __gc new Thread (__gc new[/color]
ThreadStart(pSo meClass,[color=blue]
> &SomeClass::Wri te3) );
> Thread *pthread4= __gc new Thread (__gc new[/color]
ThreadStart(pSo meClass,[color=blue]
> &SomeClass::Wri te4) );
> Thread *pthread5= __gc new Thread (__gc new[/color]
ThreadStart(pSo meClass,[color=blue]
> &SomeClass::Wri te5) );
>
>
> pthread1->Start();
> pthread2->Start();
> pthread3->Start();
> pthread4->Start();
> pthread5->Start();
>
>
> // Main thread waits for some time to let the other threads[/color]
finish[color=blue]
> Thread::Sleep(5 000);
>
> pSomeClass->DisplayValues( );
> }
>
>
> C:\c>temp
> 0 1 2 3 4 5 6 7 8[/color]
9[color=blue]
> 10 11 12 13 14 15 16 17 18[/color]
19[color=blue]
> 20 21 22 23 24 25 26 27 28[/color]
29[color=blue]
> 30 31 32 33 34 35 36 37 38[/color]
39[color=blue]
> 40 41 42 43 44 45 46 47 48[/color]
49[color=blue]
> 50 51 52 53 54 55 56 57 58[/color]
59[color=blue]
> 60 61 62 63 64 65 66 67 68[/color]
69[color=blue]
> 70 71 72 73 74 75 76 77 78[/color]
79[color=blue]
> 80 81 82 83 84 85 86 87 88[/color]
89[color=blue]
> 90 91 92 93 94 95 96 97 98[/color]
99[color=blue]
> 100 101 102 103 104 105 106 107 108[/color]
109[color=blue]
> 110 111 112 113 114 115 116 117 118[/color]
119[color=blue]
> 120 121 122 123 124 125 126 127 128[/color]
129[color=blue]
> 130 131 132 133 134 135 136 137 138[/color]
139[color=blue]
> 140 141 142 143 144 145 146 147 148[/color]
149[color=blue]
> 150 151 152 153 154 155 156 157 158[/color]
159[color=blue]
> 160 161 162 163 164 165 166 167 168[/color]
169[color=blue]
> 170 171 172 173 174 175 176 177 178[/color]
179[color=blue]
> 180 181 182 183 184 185 186 187 188[/color]
189[color=blue]
> 190 191 192 193 194 195 196 197 198[/color]
199[color=blue]
> 200 201 202 203 204 205 206 207 208[/color]
209[color=blue]
> 210 211 212 213 214 215 216 217 218[/color]
219[color=blue]
> 220 221 222 223 224 225 226 227 228[/color]
229[color=blue]
> 230 231 232 233 234 235 236 237 238[/color]
239[color=blue]
> 240 241 242 243 244 245 246 247 248[/color]
249[color=blue]
> 250 251 252 253 254 255 256 257 258[/color]
259[color=blue]
> 260 261 262 263 264 265 266 267 268[/color]
269[color=blue]
> 270 271 272 273 274 275 276 277 278[/color]
279[color=blue]
> 280 281 282 283 284 285 286 287 288[/color]
289[color=blue]
> 290 291 292 293 294 295 296 297 298[/color]
299[color=blue]
> 300 301 302 303 304 305 306 307 308[/color]
309[color=blue]
> 310 311 312 313 314 315 316 317 318[/color]
319[color=blue]
> 320 321 322 323 324 325 326 327 328[/color]
329[color=blue]
> 330 331 332 333 334 335 336 337 338[/color]
339[color=blue]
> 340 341 342 343 344 345 346 347 348[/color]
349[color=blue]
> 350 351 352 353 354 355 356 357 358[/color]
359[color=blue]
> 360 361 362 363 364 365 366 367 368[/color]
369[color=blue]
> 370 371 372 373 374 375 376 377 378[/color]
379[color=blue]
> 380 381 382 383 384 385 386 387 388[/color]
389[color=blue]
> 390 391 392 393 394 395 396 397 398[/color]
399[color=blue]
> 400 401 402 403 404 405 406 407 408[/color]
409[color=blue]
> 410 411 412 413 414 415 416 417 418[/color]
419[color=blue]
> 420 421 422 423 424 425 426 427 428[/color]
429[color=blue]
> 430 431 432 433 434 435 436 437 438[/color]
439[color=blue]
> 440 441 442 443 444 445 446 447 448[/color]
449[color=blue]
> 450 451 452 453 454 455 456 457 458[/color]
459[color=blue]
> 460 461 462 463 464 465 466 467 468[/color]
469[color=blue]
> 470 471 472 473 474 475 476 477 478[/color]
479[color=blue]
> 480 481 482 483 484 485 486 487 488[/color]
489[color=blue]
> 490 491 492 493 494 495 496 497 498[/color]
499[color=blue]
> 500 501 502 503 504 505 506 507 508[/color]
509[color=blue]
> 510 511 512 513 514 515 516 517 518[/color]
519[color=blue]
> 520 521 522 523 524 525 526 527 528[/color]
529[color=blue]
> 530 531 532 533 534 535 536 537 538[/color]
539[color=blue]
> 540 541 542 543 544 545 546 547 548[/color]
549[color=blue]
> 550 551 552 553 554 555 556 557 558[/color]
559[color=blue]
> 560 561 562 563 564 565 566 567 568[/color]
569[color=blue]
> 570 571 572 573 574 575 576 577 578[/color]
579[color=blue]
> 580 581 582 583 584 585 586 587 588[/color]
589[color=blue]
> 590 591 592 593 594 595 596 597 598[/color]
599[color=blue]
> 600 601 602 603 604 605 606 607 608[/color]
609[color=blue]
> 610 611 612 613 614 615 616 617 618[/color]
619[color=blue]
> 620 621 622 623 624 625 626 627 628[/color]
629[color=blue]
> 630 631 632 633 634 635 636 637 638[/color]
639[color=blue]
> 640 641 642 643 644 645 646 647 648[/color]
649[color=blue]
> 650 651 652 653 654 655 656 657 658[/color]
659[color=blue]
> 660 661 662 663 664 665 666 667 668[/color]
669[color=blue]
> 670 671 672 673 674 675 676 677 678[/color]
679[color=blue]
> 680 681 682 683 684 685 686 687 688[/color]
689[color=blue]
> 690 691 692 693 694 695 696 697 698[/color]
699[color=blue]
> 700 701 702 703 704 705 706 707 708[/color]
709[color=blue]
> 710 711 712 713 714 715 716 717 718[/color]
719[color=blue]
> 720 721 722 723 724 725 726 727 728[/color]
729[color=blue]
> 730 731 732 733 734 735 736 737 738[/color]
739[color=blue]
> 740 741 742 743 744 745 746 747 748[/color]
749[color=blue]
> 750 751 752 753 754 755 756 757 758[/color]
759[color=blue]
> 760 761 762 763 764 765 766 767 768[/color]
769[color=blue]
> 770 771 772 773 774 775 776 777 778[/color]
779[color=blue]
> 780 781 782 783 784 785 786 787 788[/color]
789[color=blue]
> 790 791 792 793 794 795 796 797 798[/color]
799[color=blue]
> 800 801 802 803 804 805 806 807 808[/color]
809[color=blue]
> 810 811 812 813 814 815 816 817 818[/color]
819[color=blue]
> 820 821 822 823 824 825 826 827 828[/color]
829[color=blue]
> 830 831 832 833 834 835 836 837 838[/color]
839[color=blue]
> 840 841 842 843 844 845 846 847 848[/color]
849[color=blue]
> 850 851 852 853 854 855 856 857 858[/color]
859[color=blue]
> 860 861 862 863 864 865 866 867 868[/color]
869[color=blue]
> 870 871 872 873 874 875 876 877 878[/color]
879[color=blue]
> 880 881 882 883 884 885 886 887 888[/color]
889[color=blue]
> 890 891 892 893 894 895 896 897 898[/color]
899[color=blue]
> 900 901 902 903 904 905 906 907 908[/color]
909[color=blue]
> 910 911 912 913 914 915 916 917 918[/color]
919[color=blue]
> 920 921 922 923 924 925 926 927 928[/color]
929[color=blue]
> 930 931 932 933 934 935 936 937 938[/color]
939[color=blue]
> 940 941 942 943 944 945 946 947 948[/color]
949[color=blue]
> 950 951 952 953 954 955 956 957 958[/color]
959[color=blue]
> 960 961 962 963 964 965 966 967 968[/color]
969[color=blue]
> 970 971 972 973 974 975 976 977 978[/color]
979[color=blue]
> 980 981 982 983 984 985 986 987 988[/color]
989[color=blue]
> 990 991 992 993 994 995 996 997 998[/color]
999[color=blue]
>
> C:\c>
>
>
>[color=green]
> > What other alternative do you have? If you need that multiple[/color][/color]
threads[color=blue][color=green]
> > have equal access to a shared resource then you need to lock it.[/color]
>
>
> Yes. If it is one object, however the story is different when we are[/color]
dealing with separate[color=blue]
> elements of a container which is our subject (STL).
>
>
>
>
> --
> Ioannis Vranos
>
> http://www23.brinkster.com/noicys[/color]

Of course no thread locking is required for this type of code, because
your threads are not access the same data.
Each thread has it's own block of data.
Thread synchronization is needed when you're access and modifying the
same chunck of data.
This is not an example of such a requirement, and there for no need for
a ThreadSafeObjec t wrapper class, nor is there a need for application
level lock.