STL & Multithreading

[Michael]

Don't shoot me down guys, I know the Standard says nothing of threads and
all....

As i understand it the STL does not support multithreading, however I want
to use the STL in a multithreaded environment.

Is it sufficient to declare a bool variable 'Locked' which process set when
they are using a particular object or do I need to consult some more low
level platform-kernel documentation??
Regards


Mike

 

[Victor Bazarov]

Don't shoot me down guys, I know the Standard says nothing of threads and
all....

As i understand it the STL does not support multithreading, however I want
to use the STL in a multithreaded environment.

Is it sufficient to declare a bool variable 'Locked' which process set when
they are using a particular object or do I need to consult some more low
level platform-kernel documentation??

I think you need to ask this in a newsgroup that deals with
multithreading. Sufficiency of declaring a variable and setting
of that variable cannot be judged from C++ point of view. You
said yourself, C++ says nothing about threads.

A newsgroup for your OS is probably the best for that.

V

 

[Thomas Maier-Komor]

As i understand it the STL does not support multithreading, however I want
to use the STL in a multithreaded environment.

That depends on the implementation - some actually do support threading.
Or more precisely said methods of these implementations are thread-safe.
But that alone won't make your software multithread safe, as all data
constructed with STL classes must be shared in a consistent state across
threads.

You should first get a general idea how multithreading works and what is
required, before mixing STL and threads. The STL is quite difficult to
handle in such an environment esspecially regarding iterators...

Is it sufficient to declare a bool variable 'Locked' which process set when
they are using a particular object or do I need to consult some more low
level platform-kernel documentation??

A bool variable is not enough - look for mutexes and semaphores. On a
POSIX compliant system this would be pthread_mutex_lock and friends...

 

[__PPS__]

Don't shoot me down guys, I know the Standard says nothing of threads and
all....

As i understand it the STL does not support multithreading, however I want
to use the STL in a multithreaded environment.

Is it sufficient to declare a bool variable 'Locked' which process set when
they are using a particular object or do I need to consult some more low
level platform-kernel documentation??
Regards


Mike

Bool is not enough ( ++ operator is not atomic etc...), there is no
way you can garantie something to be locked using only language
facilities - you should use mechanisms provided by the os.
As an example, your bool variable before being changed/read may sit in
a cpu register or cash memory. For multiprocessor machines you never
know what happens with this bools as they may simultaneously sit in
another processor's register/memory (processor that executes a
concurrent thread)

 

[GTO]

Which operating system? Which STL implementation? You may want to read more
about SGI's STL implementation at
http://www.sgi.com/tech/stl/thread_safety.html

Generally, it can be done by using mutex locks inside a wrapper class
(Pthread mutexes or Win32 critical sections).

Gregor

 

[Peter Koch Larsen]

Don't shoot me down guys, I know the Standard says nothing of threads and
all....

As i understand it the STL does not support multithreading, however I want
to use the STL in a multithreaded environment.

Is it sufficient to declare a bool variable 'Locked' which process set
when
they are using a particular object or do I need to consult some more low
level platform-kernel documentation??
Regards


Mike

I am not shooting you down, but as this is outside the standard you really
ought to check with the compilers documentation. My guess is that for all
compilers that support multithreading, you can use the stl containers as you
would use any other variable in a multithreaded environment. This is the
case for e.g. Microsofts compilers.

/Peter

 

[Catalin Pitis]

Which operating system? Which STL implementation? You may want to read
more about SGI's STL implementation at
http://www.sgi.com/tech/stl/thread_safety.html

Generally, it can be done by using mutex locks inside a wrapper class
(Pthread mutexes or Win32 critical sections).

Gregor

Or you can use boost thread library to have platform & compiler
independency.

Catalin

 

[Gianni Mariani]

Don't shoot me down guys, I know the Standard says nothing of threads and
all....

As i understand it the STL does not support multithreading, however I want
to use the STL in a multithreaded environment.

Is it sufficient to declare a bool variable 'Locked' which process set when
they are using a particular object or do I need to consult some more low
level platform-kernel documentation??
Regards

Some implementations of the STL are not thread safe meaning that using
distinct objects in the different threads may cause undefined befaviour.
This was at least true for GCC's 2.9* string implementation (which has
been fixed properly in gcc 3.*). Make sure the STL implementation you
do use is at least re-entrant. (Recent GCC STL, STLPORT and VC++7.1 seem
to be OK).

Others posts have good suggestions.

 

[Ioannis Vranos]

Bool is not enough ( ++ operator is not atomic etc...),

What do you mean with the above.

there is no
way you can garantie something to be locked using only language
facilities - you should use mechanisms provided by the os.
As an example, your bool variable before being changed/read may sit in
a cpu register or cash memory. For multiprocessor machines you never
know what happens with this bools as they may simultaneously sit in
another processor's register/memory (processor that executes a
concurrent thread)

Now you have placed me in thoughts. Under .NET, in a producer/consumer
relationship a common practice is to have a boolean value indicating
whether a new value has been produced or not.

For example, assuming

bool consumed=true;


A producer thread checks if this boolean is true and if yes, it assigns
a new value to the corresponding location and makes consumed=false;,
otherwise it enters the WaitSleepJoin state via a call to Monitor::Wait().


A consumer thread checks if this value is false, and if it is, it reads
the corresponding location and makes consumed=true; otherwise it enters
the WaitSleepJoin state.


This is the same variable (the data member of an object). How can it be
in the registers of two separate processors with different values each?

It doesn't sound possible.