STL & multithreading

What does the standard say about those two? Is any assurance that the
use of STL is thread safe?

Have a nice day,
Mihai.

"mihai" <Mihai.Grecu@gmail.com> wrote in message
news:1114014887.874510.162670@o13g2000cwo.googlegr oups.com...[color=blue]
> What does the standard say about those two? Is any assurance that the
> use of STL is thread safe?[/color]

No, in fact, C++ has no idea what threading even is.

- JFA1

"mihai" <Mihai.Grecu@gmail.com> wrote in message
news:1114014887.874510.162670@o13g2000cwo.googlegr oups.com...[color=blue]
> What does the standard say about those two? Is any assurance that the
> use of STL is thread safe?[/color]

We are sure that STL is NOT thread safe

Mino Saccone

"Mino Saccone" <mino.saccone@eidosmedia.com> wrote in news:d462do$os1$1
@domitilla.aioe.org:
[color=blue]
>
> "mihai" <Mihai.Grecu@gmail.com> wrote in message
> news:1114014887.874510.162670@o13g2000cwo.googlegr oups.com...[color=green]
>> What does the standard say about those two? Is any assurance that the
>> use of STL is thread safe?[/color]
>
> We are sure that STL is NOT thread safe[/color]

Well.... that depends:

1) The Standard makes no mention of threading, so from a Standard point of
view, this is an unanswerable question
2) That depends on _which_ implementation of STL you are talking about.
Many STL vendors do make some sort of claim about thread safety in their
products.

mihai wrote:
[color=blue]
> What does the standard say about those two? Is any assurance that the
> use of STL is thread safe?[/color]

A compiler that supports multithreading, usually provides a thread-safe implementation of
the standard library. Otherwise it will state in its documentation if something is not
thread safe.

--
Ioannis Vranos

http://www23.brinkster.com/noicys

mihai wrote:[color=blue]
> What does the standard say about those two? Is any assurance that the
> use of STL is thread safe?
>
> Have a nice day,
> Mihai.[/color]

In general, STL objects are not thread safe.

However, it's not that hard to make them thread safe.
Check out the following link:
http://code.axter.com/ThreadSafeObject.h

The above link contains a wrapper class that can be use in Win32 code
to make STL objects thread safe.
Once the wrapper class is declared, it acts like a pointer.

Example Usage
ThreadSafeObject<vector<int> > MyThreadSafeVectorInt(new vector<int>);
MyThreadSafeVectorInt.GetLockedObject()->push_back(123);
cout << MyThreadSafeVectorInt.GetLockedObject()->at(0) << endl;

For UNIX/Linux/OS2 it would not be to hard to modify the
ThreadSafeObject wrapper class to use POSIX functions instead of Win32
API functions.

Also see following link:
http://code.axter.com/ThreadSafeViaMutexObject.h

"mihai" <Mihai.Grecu@gmail.com> skrev i en meddelelse
news:1114014887.874510.162670@o13g2000cwo.googlegr oups.com...[color=blue]
> What does the standard say about those two? Is any assurance that the
> use of STL is thread safe?
>
> Have a nice day,
> Mihai.
>[/color]

The *standard* has no notion of threads so it can't help you. Don't worry: I
guess most libraries that are expected to work on a multithreading platform
will provide some sort of thread-safety - you just have to look it up in the
documentation. "Standard" is for the standard library containers to be "as
safe as ints", which is the IMO correct level for safety.

/Peter

"Axter" <temp@axter.com> skrev i en meddelelse
news:1114026194.982689.188320@g14g2000cwa.googlegr oups.com...[color=blue]
> mihai wrote:[color=green]
>> What does the standard say about those two? Is any assurance that the
>> use of STL is thread safe?
>>
>> Have a nice day,
>> Mihai.[/color]
>
> In general, STL objects are not thread safe.
>
> However, it's not that hard to make them thread safe.
> Check out the following link:
> http://code.axter.com/ThreadSafeObject.h
>
> The above link contains a wrapper class that can be use in Win32 code
> to make STL objects thread safe.
> Once the wrapper class is declared, it acts like a pointer.
>
> Example Usage
> ThreadSafeObject<vector<int> > MyThreadSafeVectorInt(new vector<int>);
> MyThreadSafeVectorInt.GetLockedObject()->push_back(123);
> cout << MyThreadSafeVectorInt.GetLockedObject()->at(0) << endl;
>
> For UNIX/Linux/OS2 it would not be to hard to modify the
> ThreadSafeObject wrapper class to use POSIX functions instead of Win32
> API functions.
>
> Also see following link:
> http://code.axter.com/ThreadSafeViaMutexObject.h
>[/color]

First of all, I do not see how your scheme is protecting you against a
template library that is not multithreaded. You will have problems if one of
the underlying collectionclasses access some shared variable. Secondly,
you're protecting the data at the wrong level: in general, it is not an
individual "push" operation that needs to be protected, but a larger
"logical" operation. In this common case, your protection will be at worst
useless while it in the best case only serves to eat cpu-cycles.

/Peter

Try this one if you want a thread-safe STL implementation (as already
pointed out, the C++ standard does not mention how to deal with threads):

http://www.sgi.com/tech/stl/thread_safety.html

Gregor

"mihai" <Mihai.Grecu@gmail.com> wrote in message
news:1114014887.874510.162670@o13g2000cwo.googlegr oups.com...[color=blue]
> What does the standard say about those two? Is any assurance that the
> use of STL is thread safe?
>
> Have a nice day,
> Mihai.
>[/color]

"Axter" wrote[color=blue]
> mihai wrote:[color=green]
> > What does the standard say about those two? Is any assurance that the
> > use of STL is thread safe?
> >
> > Have a nice day,
> > Mihai.[/color]
>
> In general, STL objects are not thread safe.
>
> However, it's not that hard to make them thread safe.
> Check out the following link:
> http://code.axter.com/ThreadSafeObject.h
>
> The above link contains a wrapper class that can be use in Win32 code
> to make STL objects thread safe.
> Once the wrapper class is declared, it acts like a pointer.
>
> Example Usage
> ThreadSafeObject<vector<int> > MyThreadSafeVectorInt(new vector<int>);
> MyThreadSafeVectorInt.GetLockedObject()->push_back(123);
> cout << MyThreadSafeVectorInt.GetLockedObject()->at(0) << endl;[/color]

This looks interessting, but have you also stress tested this using
multiple threads such like say 10 threads wanting to modify this vector?

Peter Koch Larsen wrote:[color=blue]
> "Axter" <temp@axter.com> skrev i en meddelelse
> news:1114026194.982689.188320@g14g2000cwa.googlegr oups.com...[color=green]
> > mihai wrote:[color=darkred]
> >> What does the standard say about those two? Is any assurance that[/color][/color][/color]
the[color=blue][color=green][color=darkred]
> >> use of STL is thread safe?
> >>
> >> Have a nice day,
> >> Mihai.[/color]
> >
> > In general, STL objects are not thread safe.
> >
> > However, it's not that hard to make them thread safe.
> > Check out the following link:
> > http://code.axter.com/ThreadSafeObject.h
> >
> > The above link contains a wrapper class that can be use in Win32[/color][/color]
code[color=blue][color=green]
> > to make STL objects thread safe.
> > Once the wrapper class is declared, it acts like a pointer.
> >
> > Example Usage
> > ThreadSafeObject<vector<int> > MyThreadSafeVectorInt(new[/color][/color]
vector<int>);[color=blue][color=green]
> > MyThreadSafeVectorInt.GetLockedObject()->push_back(123);
> > cout << MyThreadSafeVectorInt.GetLockedObject()->at(0) << endl;
> >
> > For UNIX/Linux/OS2 it would not be to hard to modify the
> > ThreadSafeObject wrapper class to use POSIX functions instead of[/color][/color]
Win32[color=blue][color=green]
> > API functions.
> >
> > Also see following link:
> > http://code.axter.com/ThreadSafeViaMutexObject.h
> >[/color]
>
> First of all, I do not see how your scheme is protecting you against[/color]
a[color=blue]
> template library that is not multithreaded. You will have problems if[/color]
one of[color=blue]
> the underlying collectionclasses access some shared variable.[/color]
Secondly,[color=blue]
> you're protecting the data at the wrong level: in general, it is not[/color]
an[color=blue]
> individual "push" operation that needs to be protected, but a larger
> "logical" operation. In this common case, your protection will be at[/color]
worst[color=blue]
> useless while it in the best case only serves to eat cpu-cycles.
>
> /Peter[/color]

IMHO, you should understand the code before jumping to such false
conclusions.

Try running, and see if you can break the code.
I'm sure you'll find that it does exactly what it's suppose to do, and
it will block more then one thread from accessing the object at the
same time.

This generic code is able to make an object thread safe, because in
order to access the object, it creates a temporary object.
The temporary object does a lock in the constructor, and then does an
unlock in the temporary object's destructor.

In the future, if the code is above your head, I recommend that you try
asking questions before posting criticisms.
How can you criticize something you don't understand?

Uenal Mutlu wrote:[color=blue]
> "Axter" wrote[color=green]
> > mihai wrote:[color=darkred]
> > > What does the standard say about those two? Is any assurance that[/color][/color][/color]
the[color=blue][color=green][color=darkred]
> > > use of STL is thread safe?
> > >
> > > Have a nice day,
> > > Mihai.[/color]
> >
> > In general, STL objects are not thread safe.
> >
> > However, it's not that hard to make them thread safe.
> > Check out the following link:
> > http://code.axter.com/ThreadSafeObject.h
> >
> > The above link contains a wrapper class that can be use in Win32[/color][/color]
code[color=blue][color=green]
> > to make STL objects thread safe.
> > Once the wrapper class is declared, it acts like a pointer.
> >
> > Example Usage
> > ThreadSafeObject<vector<int> > MyThreadSafeVectorInt(new[/color][/color]
vector<int>);[color=blue][color=green]
> > MyThreadSafeVectorInt.GetLockedObject()->push_back(123);
> > cout << MyThreadSafeVectorInt.GetLockedObject()->at(0) << endl;[/color]
>
> This looks interessting, but have you also stress tested this using
> multiple threads such like say 10 threads wanting to modify this[/color]
vector?

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.

Axter wrote:[color=blue]
>
> Try running, and see if you can break the code.[/color]

while (!vec.empty())
vec.pop_back();

If the code doesn't lock around the entire loop it will break. Sooner or
later you'll get a thread switch right after the call to empty returns
false, and the vector may, in fact, be empty for the call to pop_back.

As Peter said, locking containers doesn't make an application
thread-safe. And once you've added the high-level protection that's
needed to make the application thread-safe, locks in containers will
usually be redundant.

--

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

Peter Koch Larsen wrote:[color=blue]
> "Axter" <temp@axter.com> skrev i en meddelelse
> news:1114026194.982689.188320@g14g2000cwa.googlegr oups.com...[color=green]
> > mihai wrote:[color=darkred]
> >> What does the standard say about those two? Is any assurance that[/color][/color][/color]
the[color=blue][color=green][color=darkred]
> >> use of STL is thread safe?
> >>
> >> Have a nice day,
> >> Mihai.[/color]
> >
> > In general, STL objects are not thread safe.
> >
> > However, it's not that hard to make them thread safe.
> > Check out the following link:
> > http://code.axter.com/ThreadSafeObject.h
> >
> > The above link contains a wrapper class that can be use in Win32[/color][/color]
code[color=blue][color=green]
> > to make STL objects thread safe.
> > Once the wrapper class is declared, it acts like a pointer.
> >
> > Example Usage
> > ThreadSafeObject<vector<int> > MyThreadSafeVectorInt(new[/color][/color]
vector<int>);[color=blue][color=green]
> > MyThreadSafeVectorInt.GetLockedObject()->push_back(123);
> > cout << MyThreadSafeVectorInt.GetLockedObject()->at(0) << endl;
> >
> > For UNIX/Linux/OS2 it would not be to hard to modify the
> > ThreadSafeObject wrapper class to use POSIX functions instead of[/color][/color]
Win32[color=blue][color=green]
> > API functions.
> >
> > Also see following link:
> > http://code.axter.com/ThreadSafeViaMutexObject.h
> >[/color]
>
> First of all, I do not see how your scheme is protecting you against[/color]
a[color=blue]
> template library that is not multithreaded. You will have problems if[/color]
one of[color=blue]
> the underlying collectionclasses access some shared variable.[/color]
Secondly,[color=blue]
> you're protecting the data at the wrong level: in general, it is not[/color]
an[color=blue]
> individual "push" operation that needs to be protected, but a larger
> "logical" operation. In this common case, your protection will be at[/color]
worst[color=blue]
> useless while it in the best case only serves to eat cpu-cycles.
>
> /Peter[/color]

After re-reading your comments, I think I understand your
misunderstanding.
The wrapper class I posted does not make the CLASS thread safe. The
wrapper class makes the object itself thread safe.

It prevents the object from being access at the same time from multiple
threads.

It does not stop the object from accessing another object that is not
thread safe.
So if you have an STL implementation that shares variables with
multiple instances of a class, then the wrapper class will not help.

You should be using a thread safe CLASS with the wrapper class.

Pete Becker wrote:[color=blue]
> Axter wrote:[color=green]
> >
> > Try running, and see if you can break the code.[/color]
>
> while (!vec.empty())
> vec.pop_back();
>
> If the code doesn't lock around the entire loop it will break. Sooner[/color]
or[color=blue]
> later you'll get a thread switch right after the call to empty[/color]
returns[color=blue]
> false, and the vector may, in fact, be empty for the call to[/color]
pop_back.[color=blue]
>
> As Peter said, locking containers doesn't make an application
> thread-safe. And once you've added the high-level protection that's
> needed to make the application thread-safe, locks in containers will
> usually be redundant.
>
> --
>
> Pete Becker
> Dinkumware, Ltd. (http://www.dinkumware.com)[/color]

Please read the entire posted thread. I'm not talking about a vector
by itself. You're above code is not using the wrapper class which is
what I was referring to in my previous post.
I'm talking about an object wrapped in the thread safe wrapper class.
See following link:
http://code.axter.com/ThreadSa*feObject.h

Axter wrote:[color=blue]
>
> I'm not talking about a vector
> by itself. You're above code is not using the wrapper class which is
> what I was referring to in my previous post.[/color]

The point is that with or without the wrapper class this use of the
container is not thread-safe. You need an application-level policy and
broader locking. Thread-safe containers are not sufficient, and are
usually redundant.

--

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

Pete Becker wrote:[color=blue]
> Axter wrote:[color=green]
> >
> > I'm not talking about a vector
> > 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.[/color]
>
> The point is that with or without the wrapper class this use of the
> container is not thread-safe. You need an application-level policy[/color]
and[color=blue]
> broader locking. Thread-safe containers are not sufficient, and are
> usually redundant.
>
> --
>
> Pete Becker
> Dinkumware, Ltd. (http://www.dinkumware.com)[/color]

Can you prove that point with some type of example code that would
break?
And I'm not referring to a class that shares objects with multiple
instances of the class.
I'm referring to a typical class that has no shared objects.
Show me how a class like that would break using a thread-safe wrapper
class.

"Axter" <temp@axter.com> wrote in news:1114206648.687320.109050
@f14g2000cwb.googlegroups.com:
[color=blue]
> Pete Becker wrote:[color=green]
>> Axter wrote:[color=darkred]
>> >
>> > Try running, and see if you can break the code.[/color]
>>
>> while (!vec.empty())
>> vec.pop_back();
>>
>> If the code doesn't lock around the entire loop it will break. Sooner[/color]
> or[color=green]
>> later you'll get a thread switch right after the call to empty[/color]
> returns[color=green]
>> false, and the vector may, in fact, be empty for the call to[/color]
> pop_back.[color=green]
>>
>> As Peter said, locking containers doesn't make an application
>> thread-safe. And once you've added the high-level protection that's
>> needed to make the application thread-safe, locks in containers will
>> usually be redundant.
>>
>> --
>>
>> Pete Becker
>> Dinkumware, Ltd. (http://www.dinkumware.com)[/color]
>
>
> Please read the entire posted thread. I'm not talking about a vector
> by itself. You're above code is not using the wrapper class which is
> what I was referring to in my previous post.
> I'm talking about an object wrapped in the thread safe wrapper class.
> See following link:
> http://code.axter.com/ThreadSa*feObject.h
>
>[/color]

Yes, he was talking about using your wrapper class. It was simply not
shown in the code example for brevity's sake. So to rephrase:

while (!vec.empty())
vec.pop_back();

Replace "vec." with "obj->GetLockedObject()->". So let's assume we start
with a 1000000 element vector, and we launch 100 threads with the above
code in it to clear out the vector (and for some strange reason we don't
want to just .clear() it...).

Let's continue the example that say we're down to the last element, and
25 of the threads check vec.empty() and then there's a thread context
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 switch.
Say the remaining 74 threads are the ones that get the next contexts.
They all test vec.empty(), find the vector empty, and proceed along their
codepath. Finally those first 25 that were sitting just after the
vec.empty() call get their timeslices. All 25 will attempt a pop_back on
an empty vector. Boom. (OK, Undefined Behaviour)

Translation, your wrapper class does _not_ provide thread safety as a
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 the
two operations where the state of the object may be modified.

Axter wrote:[color=blue]
>
> Can you prove that point with some type of example code that would
> break?[/color]

I gave you an example and I explained it. Do you have questions about
that example?

--

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

Pete Becker wrote:
[color=blue]
> The point is that with or without the wrapper class this use of the
> container is not thread-safe. You need an application-level policy and
> broader locking. Thread-safe containers are not sufficient, and are
> usually redundant.[/color]

With wrapper classes aside, do you think that there are not multithreading-enabled STL
implementations? I am not sure what you mean with the redundant part too.

But first let's define what we mean with "thread-safety". I assume we are talking about
different threads accessing safely different parts of a container (like a vector) and
calling a given function concurrently, right?

--
Ioannis Vranos

http://www23.brinkster.com/noicys

Axter wrote:
[color=blue]
> 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.

--
Ioannis Vranos

http://www23.brinkster.com/noicys

Ioannis Vranos wrote:
[color=blue]
> With wrapper classes aside, do you think that there are not
> multithreading-enabled STL implementations? I am not sure what you mean
> with the redundant part too.
>
> But first let's define what we mean with "thread-safety". I assume we
> are talking about different threads accessing safely different parts of
> a container (like a vector)[/color]

or
[color=blue]
> calling a given function concurrently,
> right?[/color]

--
Ioannis Vranos

http://www23.brinkster.com/noicys

Ioannis Vranos wrote:[color=blue]
> Pete Becker wrote:
>[color=green]
>> The point is that with or without the wrapper class this use of the
>> container is not thread-safe. You need an application-level policy and
>> broader locking. Thread-safe containers are not sufficient, and are
>> usually redundant.[/color]
>
>
>
> With wrapper classes aside, do you think that there are not
> multithreading-enabled STL implementations? I am not sure what you mean
> with the redundant part too.
>
> But first let's define what we mean with "thread-safety". I assume we
> are talking about different threads accessing safely different parts of
> a container (like a vector) and calling a given function concurrently,
> right?
>
>
>[/color]

For the third time: to write a thread-safe application you need an
application-level locking policy and application-level locks. Using
thread-safe containers does not make your application thread-safe, and
application-level locks usually make container-level locks redundant.
See the example that I gave earlier.

--

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

Pete Becker wrote:[color=blue]
> Ioannis Vranos wrote:[color=green]
> > Pete Becker wrote:
> >[color=darkred]
> >> The point is that with or without the wrapper class this use of[/color][/color][/color]
the[color=blue][color=green][color=darkred]
> >> container is not thread-safe. You need an application-level policy[/color][/color][/color]
and[color=blue][color=green][color=darkred]
> >> broader locking. Thread-safe containers are not sufficient, and[/color][/color][/color]
are[color=blue][color=green][color=darkred]
> >> usually redundant.[/color]
> >
> >
> >
> > With wrapper classes aside, do you think that there are not
> > multithreading-enabled STL implementations? I am not sure what you[/color][/color]
mean[color=blue][color=green]
> > with the redundant part too.
> >
> > But first let's define what we mean with "thread-safety". I assume[/color][/color]
we[color=blue][color=green]
> > are talking about different threads accessing safely different[/color][/color]
parts of[color=blue][color=green]
> > a container (like a vector) and calling a given function[/color][/color]
concurrently,[color=blue][color=green]
> > right?
> >
> >
> >[/color]
>
> For the third time: to write a thread-safe application you need an
> application-level locking policy and application-level locks. Using
> thread-safe containers does not make your application thread-safe,[/color]
and[color=blue]
> application-level locks usually make container-level locks redundant.[/color]
[color=blue]
> See the example that I gave earlier.
>
> --
>
> Pete Becker
> Dinkumware, Ltd. (http://www.dinkumware.com)[/color]

Saying it a third time doesn't make it true.
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.
This is fine for programs like C, but a more OO style language should
lean to a more Object Orientated approach.

By setting up the code so the object itself has the lock, you make the
code more OO, and safer then if you used the application level lock
approach.

Axter wrote:[color=blue]
>
> 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 to
that example and that explanation there is no point in any further
discussion.

--

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

Andre Kostur wrote:[color=blue]
> "Axter" <temp@axter.com> wrote in news:1114206648.687320.109050
> @f14g2000cwb.googlegroups.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/ThreadSa*feObject.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->GetLockedObject()->". 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...).[/color]

A thread safe object is not going to stop you from performing bad logic
in multiple threads.
A thread safe object's main job is to only allow ONE thread to access
it any given time. That's it.....
[color=blue]
> 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)[/color]
If a thread needs to perform an operation that requires the state to be
stable between multiple access to the object, then using the thread
safe wrapper you can create a RefLock object. This will allow the
object to be locked while you perform multiple operations with it.
Example:
ThreadSafeObject<vector<int> >::RefLock MyLockedVec =
MyRefVectorInstance.GetLockedObject();
if (MyLockedVec->size() > 10000 && MyLockedVec->size()&1) //Due odd
numbers
{
MyLockedVec->pop_back();
}

[color=blue]
> 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.

Pete Becker wrote:
[color=blue]
> For the third time: to write a thread-safe application you need an
> application-level locking policy and application-level locks.[/color]

Yes, this on the application-level logic (and in addition to other multithreading
mechanisms that do not involve locks).

[color=blue]
> Using
> thread-safe containers does not make your application thread-safe, and
> application-level locks usually make container-level locks redundant.
> See the example that I gave earlier.[/color]

Yes in the application-level logic having a container like vector thread-safe does not
make thread-safe the access of the same container element by two or more threads
simultaneously.

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.

A practical example I can give on this is construct-level multithreading, with OpenMP
standard supported by many C++ compilers (and even more in the future). VC++ 2005 will
also support this.

#include <vector>

int main()
{
using namespace std;

vector<int> vec(100);

// ...

#pragma omp for
for(vector<int>::size_type i=0; i<vec.size(); ++i)
vec[i]= i;
}

With this OpenMP #pragma directive, you provide the guarantee that each element
access/modification is independent of the others, so the compiler generates more than 1
threads for the assignments. In this code for example, when using one of the upcoming
multi-core AMD/Intel processors, or an existing multi-processor system, the assignments
will take advantage of the two or more processors/cores and finish in less time than in
the usual single thread case.

OpenMP multithreading is independent from other application-level multithreading
mechanisms provided in a system. Also in a compiler not supporting OpenMP, as the standard
mentions, unknown #pragmas are ignored, so the code remains portable.

In a container like this, what I consider as thread safe is a container that would not
interfere a specific element access to another element.

--
Ioannis Vranos

http://www23.brinkster.com/noicys

Axter wrote:
[color=blue]
> Saying it a third time doesn't make it true.
> Container locks do work.
> If you have a container lock, then that makes the application lock
> redundant.[/color]

I am not sure I can understand you in this. Yes, one container may acquire the lock when
writing assigning a value to one of its elements for example, however when writing other
application parts, for example network connections (or a simpler example, games), one has
to use application-level multithreading either to avoid application freezing in the first
case or to take advantage of multiprocessor systems in both cases.

[color=blue]
> Using an application lock is more of a procedural based logic
> mentality.
> This is fine for programs like C, but a more OO style language should
> lean to a more Object Orientated approach.
>
> By setting up the code so the object itself has the lock, you make the
> code more OO, and safer then if you used the application level lock
> approach.[/color]

I have experience in .NET multithreading which is purely OO, yes a good practice is to
make every component multithreading from the bottom up, but this involves more than
containers, it is about thread-lock in the application level, unless you do not consider
objects as part of the application-level, in which case it would be better to clarify what
exactly do you consider this, and what you consider as application-level multithreading.

--
Ioannis Vranos

http://www23.brinkster.com/noicys

Ioannis Vranos wrote:
[color=blue]
> Yes in the application-level logic having a container like vector
> thread-safe does not make thread-safe the access of the same container
> element by two or more threads simultaneously.[/color]

Actually it can make this access thread-safe if the container uses locks. So you may
forget this paragraph.

--
Ioannis Vranos

http://www23.brinkster.com/noicys

Ioannis Vranos wrote:[color=blue]
>
> 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. Axter's assertion was that STL containers are not
thread-safe, and that adding his wrapper makes them thread-safe. Under
this criterion, he's wrong about every implementation of STL that I know
of and he's wrong about what his wrapper does.

--

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

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.

"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?

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

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)

Andre Kostur wrote:[color=blue]
> "Axter" <temp@axter.com> wrote in news:1114206648.687320.109050
> @f14g2000cwb.googlegroups.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/ThreadSa*feObject.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->GetLockedObject()->". 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:

ThreadSafeObject<std::vector<int> >::RefLock MyLockedVec =
MyRefThreadSafeOjbectTestCase.MyThreadSafeVectorIn stance.GetLockedObject();
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 ThreadSafeObject class to allow the objects to be access in a
thread safe manner.

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

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 ThreadSafeObject wrapper
class works.
If you disagree, please post proven tested code, that will show it to
break, and not unproven theories.

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.

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/de...rdCLibrary.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

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_ThreadsafeClass
{
public:
I_AM_A_ThreadsafeClass(int x):m_x(x){}
I_AM_A_ThreadsafeClass(const
I_AM_A_ThreadsafeClass&src):m_x(src.m_x){}
I_AM_A_ThreadsafeClass& operator=(const I_AM_A_ThreadsafeClass& src)
{
if (&src != this)
{
m_x = src.m_x;
}
return *this;
}
int ThreadSafeFunction(){return m_x;}
private:
int m_x;
};
class Not_A_ThreadsafeClass
{
public:
Not_A_ThreadsafeClass(int x):m_x(NotAThreadSafeFunction(x)){}
Not_A_ThreadsafeClass(const
Not_A_ThreadsafeClass&src):m_x(NotAThreadSafeFunct ion(src.m_x)){}
Not_A_ThreadsafeClass& operator=(const Not_A_ThreadsafeClass& src)
{
if (&src != this)
{
m_x = NotAThreadSafeFunction(src.m_x);
}
return *this;
}
int NotAThreadSafeFunction(int x)
{
static int NotTrheadSafe = 0;
NotTrheadSafe +=x;
return NotTrheadSafe;
}
private:
int m_x;
};

"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 "transparent".
[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.

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?

"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 synchronizations 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.

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.

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_type i=0; i<200; ++i)
(*pvec)[i]= i;
}

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

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

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

void Write5()
{
for(std::vector<int>::size_type 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::Threading;
using namespace std;

SomeClass *pSomeClass= __gc new SomeClass;

Thread *pthread1= __gc new Thread (__gc new ThreadStart(pSomeClass,
&SomeClass::Write1) );
Thread *pthread2= __gc new Thread (__gc new ThreadStart(pSomeClass,
&SomeClass::Write2) );
Thread *pthread3= __gc new Thread (__gc new ThreadStart(pSomeClass,
&SomeClass::Write3) );
Thread *pthread4= __gc new Thread (__gc new ThreadStart(pSomeClass,
&SomeClass::Write4) );
Thread *pthread5= __gc new Thread (__gc new ThreadStart(pSomeClass,
&SomeClass::Write5) );

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

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

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

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_type i=0; i<200; ++i)
> (*pvec)[i]= i;
> }
>
> void Write2()
> {
> for(std::vector<int>::size_type i=200; i<400; ++i)
> (*pvec)[i]= i;
> }
>
> void Write3()
> {
> for(std::vector<int>::size_type i=400; i<600; ++i)
> (*pvec)[i]= i;
> }
>
> void Write4()
> {
> for(std::vector<int>::size_type i=600; i<800; ++i)
> (*pvec)[i]= i;
> }
>
> void Write5()
> {
> for(std::vector<int>::size_type 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::Threading;
> using namespace std;
>
>
> SomeClass *pSomeClass= __gc new SomeClass;
>
> Thread *pthread1= __gc new Thread (__gc new[/color]
ThreadStart(pSomeClass,[color=blue]
> &SomeClass::Write1) );
> Thread *pthread2= __gc new Thread (__gc new[/color]
ThreadStart(pSomeClass,[color=blue]
> &SomeClass::Write2) );
> Thread *pthread3= __gc new Thread (__gc new[/color]
ThreadStart(pSomeClass,[color=blue]
> &SomeClass::Write3) );
> Thread *pthread4= __gc new Thread (__gc new[/color]
ThreadStart(pSomeClass,[color=blue]
> &SomeClass::Write4) );
> Thread *pthread5= __gc new Thread (__gc new[/color]
ThreadStart(pSomeClass,[color=blue]
> &SomeClass::Write5) );
>
>
> 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(5000);
>
> 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 ThreadSafeObject wrapper class, nor is there a need for application
level lock.

Axter wrote:
[color=blue][color=green]
>>#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_type i=0; i<200; ++i)
>> (*pvec)[i]= i;
>> }
>>
>> void Write2()
>> {
>> for(std::vector<int>::size_type i=200; i<400; ++i)
>> (*pvec)[i]= i;
>> }
>>
>> void Write3()
>> {
>> for(std::vector<int>::size_type i=400; i<600; ++i)
>> (*pvec)[i]= i;
>> }
>>
>> void Write4()
>> {
>> for(std::vector<int>::size_type i=600; i<800; ++i)
>> (*pvec)[i]= i;
>> }
>>
>> void Write5()
>> {
>> for(std::vector<int>::size_type 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=green]
>> cout<<*p<<"\t";
>> }
>>};
>>
>>
>>int main()
>>{
>> using namespace System;
>> using namespace System::Threading;
>> using namespace std;
>>
>>
>> SomeClass *pSomeClass= __gc new SomeClass;
>>
>> Thread *pthread1= __gc new Thread (__gc new[/color]
>
> ThreadStart(pSomeClass,
>[color=green]
>>&SomeClass::Write1) );
>> Thread *pthread2= __gc new Thread (__gc new[/color]
>
> ThreadStart(pSomeClass,
>[color=green]
>>&SomeClass::Write2) );
>> Thread *pthread3= __gc new Thread (__gc new[/color]
>
> ThreadStart(pSomeClass,
>[color=green]
>>&SomeClass::Write3) );
>> Thread *pthread4= __gc new Thread (__gc new[/color]
>
> ThreadStart(pSomeClass,
>[color=green]
>>&SomeClass::Write4) );
>> Thread *pthread5= __gc new Thread (__gc new[/color]
>
> ThreadStart(pSomeClass,
>[color=green]
>>&SomeClass::Write5) );
>>
>>
>> pthread1->Start();
>> pthread2->Start();
>> pthread3->Start();
>> pthread4->Start();
>> pthread5->Start();
>>
>>
>> // Main thread waits for some time to let the other threads[/color]
>
> finish
>[color=green]
>> Thread::Sleep(5000);
>>
>> pSomeClass->DisplayValues();
>>}[/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 ThreadSafeObject wrapper class, nor is there a need for application
> level lock.[/color]

Exactly. Still the vector along with the rest standard library in the specific compiler is
"thread-safe" in the sense that it allows multithreading operations on it.

If the vector wasn't "thread-safe", then the above assignments would not be well defined.

In the case of accessing the same data, of course thread-locking is needed, but this is in
the application's logic.

Wrapping the entire vector however, and acquiring the lock at each different element
access would be inefficient, wouldn't it?

--
Ioannis Vranos

http://www23.brinkster.com/noicys

Ioannis Vranos wrote:[color=blue]
> Axter wrote:
>[color=green][color=darkred]
> >>#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_type i=0; i<200; ++i)
> >> (*pvec)[i]= i;
> >> }
> >>
> >> void Write2()
> >> {
> >> for(std::vector<int>::size_type i=200; i<400; ++i)
> >> (*pvec)[i]= i;
> >> }
> >>
> >> void Write3()
> >> {
> >> for(std::vector<int>::size_type i=400; i<600; ++i)
> >> (*pvec)[i]= i;
> >> }
> >>
> >> void Write4()
> >> {
> >> for(std::vector<int>::size_type i=600; i<800; ++i)
> >> (*pvec)[i]= i;
> >> }
> >>
> >> void Write5()
> >> {
> >> for(std::vector<int>::size_type 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=darkred]
> >> cout<<*p<<"\t";
> >> }
> >>};
> >>
> >>
> >>int main()
> >>{
> >> using namespace System;
> >> using namespace System::Threading;
> >> using namespace std;
> >>
> >>
> >> SomeClass *pSomeClass= __gc new SomeClass;
> >>
> >> Thread *pthread1= __gc new Thread (__gc new[/color]
> >
> > ThreadStart(pSomeClass,
> >[color=darkred]
> >>&SomeClass::Write1) );
> >> Thread *pthread2= __gc new Thread (__gc new[/color]
> >
> > ThreadStart(pSomeClass,
> >[color=darkred]
> >>&SomeClass::Write2) );
> >> Thread *pthread3= __gc new Thread (__gc new[/color]
> >
> > ThreadStart(pSomeClass,
> >[color=darkred]
> >>&SomeClass::Write3) );
> >> Thread *pthread4= __gc new Thread (__gc new[/color]
> >
> > ThreadStart(pSomeClass,
> >[color=darkred]
> >>&SomeClass::Write4) );
> >> Thread *pthread5= __gc new Thread (__gc new[/color]
> >
> > ThreadStart(pSomeClass,
> >[color=darkred]
> >>&SomeClass::Write5) );
> >>
> >>
> >> pthread1->Start();
> >> pthread2->Start();
> >> pthread3->Start();
> >> pthread4->Start();
> >> pthread5->Start();
> >>
> >>
> >> // Main thread waits for some time to let the other threads[/color]
> >
> > finish
> >[color=darkred]
> >> Thread::Sleep(5000);
> >>
> >> pSomeClass->DisplayValues();
> >>}[/color]
> >
> > Of course no thread locking is required for this type of code,[/color][/color]
because[color=blue][color=green]
> > 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[/color][/color]
the[color=blue][color=green]
> > same chunck of data.
> > This is not an example of such a requirement, and there for no need[/color][/color]
for[color=blue][color=green]
> > a ThreadSafeObject wrapper class, nor is there a need for[/color][/color]
application[color=blue][color=green]
> > level lock.[/color]
>
>
>
> Exactly. Still the vector along with the rest standard library in the[/color]
specific compiler is[color=blue]
> "thread-safe" in the sense that it allows multithreading operations[/color]
on it.

I never claim that compilers do not have thread safe classes. Did you
not read my detailed explanation on the difference between a thread
safe class and a thread safe object?
[color=blue]
> If the vector wasn't "thread-safe", then the above assignments would[/color]
not be well defined.

That's right, and this has nothing to do with needing a thread safe
object. This is only relevant to thread safe class.
[color=blue]
> In the case of accessing the same data, of course thread-locking is[/color]
needed, but this is in[color=blue]
> the application's logic.
> Wrapping the entire vector however, and acquiring the lock at each[/color]
different element[color=blue]
> access would be inefficient, wouldn't it?
>[/color]

In the example code you posted, it would be inefficient and completely
unnecessary to lock the entire vector.
However, if you need to modify the vector itself, to include increasing
and decreasing the size of the vector, then wrapping the entire vector
would be the more efficient and the safer approach. It would be more
inefficient to apply an entire application level lock just for the
locking requirements of one object.
If you put your OOP hat on, this would be easier to understand.
The class wrapper method is not only more object orientated, but its
safer, it's easier to maintain, and can be more efficient.

Ioannis Vranos wrote:[color=blue]
> Axter wrote:
>[color=green][color=darkred]
> >>#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_type i=0; i<200; ++i)
> >> (*pvec)[i]= i;
> >> }
> >>
> >> void Write2()
> >> {
> >> for(std::vector<int>::size_type i=200; i<400; ++i)
> >> (*pvec)[i]= i;
> >> }
> >>
> >> void Write3()
> >> {
> >> for(std::vector<int>::size_type i=400; i<600; ++i)
> >> (*pvec)[i]= i;
> >> }
> >>
> >> void Write4()
> >> {
> >> for(std::vector<int>::size_type i=600; i<800; ++i)
> >> (*pvec)[i]= i;
> >> }
> >>
> >> void Write5()
> >> {
> >> for(std::vector<int>::size_type 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=darkred]
> >> cout<<*p<<"\t";
> >> }
> >>};
> >>
> >>
> >>int main()
> >>{
> >> using namespace System;
> >> using namespace System::Threading;
> >> using namespace std;
> >>
> >>
> >> SomeClass *pSomeClass= __gc new SomeClass;
> >>
> >> Thread *pthread1= __gc new Thread (__gc new[/color]
> >
> > ThreadStart(pSomeClass,
> >[color=darkred]
> >>&SomeClass::Write1) );
> >> Thread *pthread2= __gc new Thread (__gc new[/color]
> >
> > ThreadStart(pSomeClass,
> >[color=darkred]
> >>&SomeClass::Write2) );
> >> Thread *pthread3= __gc new Thread (__gc new[/color]
> >
> > ThreadStart(pSomeClass,
> >[color=darkred]
> >>&SomeClass::Write3) );
> >> Thread *pthread4= __gc new Thread (__gc new[/color]
> >
> > ThreadStart(pSomeClass,
> >[color=darkred]
> >>&SomeClass::Write4) );
> >> Thread *pthread5= __gc new Thread (__gc new[/color]
> >
> > ThreadStart(pSomeClass,
> >[color=darkred]
> >>&SomeClass::Write5) );
> >>
> >>
> >> pthread1->Start();
> >> pthread2->Start();
> >> pthread3->Start();
> >> pthread4->Start();
> >> pthread5->Start();
> >>
> >>
> >> // Main thread waits for some time to let the other threads[/color]
> >
> > finish
> >[color=darkred]
> >> Thread::Sleep(5000);
> >>
> >> pSomeClass->DisplayValues();
> >>}[/color]
> >
> > Of course no thread locking is required for this type of code,[/color][/color]
because[color=blue][color=green]
> > 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[/color][/color]
the[color=blue][color=green]
> > same chunck of data.
> > This is not an example of such a requirement, and there for no need[/color][/color]
for[color=blue][color=green]
> > a ThreadSafeObject wrapper class, nor is there a need for[/color][/color]
application[color=blue][color=green]
> > level lock.[/color]
>
>
>
> Exactly. Still the vector along with the rest standard library in the[/color]
specific compiler is[color=blue]
> "thread-safe" in the sense that it allows multithreading operations[/color]
on it.[color=blue]
>
> If the vector wasn't "thread-safe", then the above assignments would[/color]
not be well defined.[color=blue]
>
>
> In the case of accessing the same data, of course thread-locking is[/color]
needed, but this is in[color=blue]
> the application's logic.
>
>
> Wrapping the entire vector however, and acquiring the lock at each[/color]
different element[color=blue]
> access would be inefficient, wouldn't it?
>
>
>
> --
> Ioannis Vranos
>
> http://www23.brinkster.com/noicys[/color]

I forgot to mention, that if you have manage code, like the code you
posted, you don't need the ThreadSafeObject class I posted.
..Net has a Monitor class that can do this object base locking for you.
The syntax is something like the following:
Monitor::Enter(pvec);
//do something with pvec here
Monitor::Exit(pvec);

If object level locking is not needed for your compiler, do you think
MS would have wasted time creating this Monitor class?

STL & multithreading

re: STL & multithreading

re: STL & multithreading

re: STL & multithreading

re: STL & multithreading

re: STL & multithreading

re: STL & multithreading

re: STL & multithreading

re: STL & multithreading

re: STL & multithreading

re: STL & multithreading

re: STL & multithreading

re: STL & multithreading

re: STL & multithreading

re: STL & multithreading

re: STL & multithreading

re: STL & multithreading

re: STL & multithreading

re: STL & multithreading

re: STL & multithreading

re: STL & multithreading

re: STL & multithreading

re: STL & multithreading

re: STL & multithreading

re: STL & multithreading

re: STL & multithreading

re: STL & multithreading

re: STL & multithreading

re: STL & multithreading

re: STL & multithreading

re: STL & multithreading

re: STL & multithreading

re: STL & multithreading

re: STL & multithreading

re: STL & multithreading

re: STL & multithreading

re: STL & multithreading

re: STL & multithreading

re: STL & multithreading

re: STL & multithreading

re: STL & multithreading

re: STL & multithreading

re: STL & multithreading

re: STL & multithreading

re: STL & multithreading

re: STL & multithreading

re: STL & multithreading

re: STL & multithreading

Similar C / C++ bytes

/bytes/development

/bytes/it

/bytes/about