I know this is really a C++, not Win32 question, but I don't hang
around any C++ group, so please tolerate.

If an object is instantiated in the main thread of a program, but
allocates memory when referenced in a worker thread, should that
memory be accessible by the main thread once the worker thread ends?

Example:
I have a class (PFBitMap) that handles BMP and JPEG files. PFBitMap
uses objects in a class (PFString) that handles strings (for filename,
date stamp, etc.). When a PFBitMap object is instantiated, it
instantiates all its PFString objects.

PFString objects allocate memory dynamically (using new).

My program instantiates a few PFBitMap objects. I want to use a worker
thread when one of these objects reads a file. But I ran into problems
when the main thread tried to access the PFString objects (e.g. a date
stamp). No problems if I read files in the main thread or if I make
pre-allocate all the PFStrings.

Pre-allocating the strings seems like a good solution, but I would
like feedback.

Thanks.
-----------------------------------------
To reply to me, remove the underscores (_) from my email address (and please indicate which newsgroup and message).

Robert E. Zaret, eMVP
PenFact, Inc.
20 Park Plaza, Suite 400
Boston, MA 02116
www.penfact.com
Useful reading (be sure to read its disclaimer first):
http://catb.org/~esr/faqs/smart-questions.html

<r_z_aret@pen_fact.com> wrote in message
news:beob24lql7q9jm5dtgqv3rda93230qfsu3@4ax.com...
source code):
1. Thread A tries to access string which wasn't yet created by thread B (or
is in process of being created). Mutexes/critical sections can be used to
sync access by multiple threads.
2. On multi-core/multi-processor systems different threads could have
different views of same memory location. That's because different threads
could be executing on different CPUs/cores at same time - and CPUs/cores
generally optimize handling of data in memory. Simplified explanation: CPUs
store modifications to memory locations internally and flush them (into main
memory) only when needed - things are generally more complicated than that.
Anyway, there're ways to make views (of a memory location or of the whole of
memory) by all CPUs/cores consistent.
How achieve it: if using a recent Microsoft C/C++ compiler (VS2005 and up)
it's sufficient to declare shared variable (to be accessed by multiple
threads) as 'volatile'. With earlier MS compilers, you would need to call
some of memory fence (mfence) functions (which are part of C-Runtime
library) before after modifying the shared variable. Also, same as for (1):
mutex/critical section can used when accessing shared variable - that's
because acquiring mutex/critical section always executes mfence
functionality.

Boris

<r_z_aret@pen_fact.com> wrote in message
news:beob24lql7q9jm5dtgqv3rda93230qfsu3@4ax.com...
Yes. All threads share the same memory. If your worker thread does not
delete things it created then they remain in memory, even after the worker
thread ends.

The problems you can run into involve synchronization between threads. If
the worker thread changes some data, such as a string, there is a point in
time when only part of that data has been changed. At that point in time,
if the main thread trys to read the shared data very bad things can happen,
since the data is in an invalid state. When two or more threads are going
to access the same data, and the data can change, you must provide
synchronization so that only one thread at a time is permitted to access the
data.

In Win32 interthread synchronization can be provided with
EnterCriticalSection and LeaveCriticalSection. Every thread must call
Enter... before accessing the shared data, and Leave... after it is done.
When a thread calls Enter... it is forced to wait if some other thread is
between the two calls. When the other thread Leaves..., the first thread is
permitted to proceed.

--
Scott McPhillips [VC++ MVP]

On Sat, 10 May 2008 19:08:04 -0400, "Scott McPhillips [MVP]"
<org-dot-mvps-at-scottmcp> wrote:

I get the error even when I wait (at a debug break in the main thread)
several seconds (I'm pretty sure I've waited over a minute) after the
thread terminates before attempting to access the problematic memory.
The symptoms go away when I allocate all the strings in the main
thread before starting the worker thread.

I use the thread to read the likely next picture. I start the worker
thread, and then the main thread doesn't do anything to the object in
the worker thread (or start another thread) until the worker thread
stops (I use a WaitAndPump function), or my wait times out. Meanwhile,
the user can look at the previous picture, resize the screen, stop the
program, and a few other UI-type things. All very safe, unless the
wait times out; for now I have a long interval (100 seconds), the
program is non-critical, and I'm the only user, but I'll work on this
hole.


-----------------------------------------
To reply to me, remove the underscores (_) from my email address (and please indicate which newsgroup and message).

Robert E. Zaret, eMVP
PenFact, Inc.
20 Park Plaza, Suite 400
Boston, MA 02116
www.penfact.com
Useful reading (be sure to read its disclaimer first):
http://catb.org/~esr/faqs/smart-questions.html

On Sat, 10 May 2008 12:50:23 -0700, "boris" <someone@nospam.net>
wrote:

I can't think of a way to provide enough code to be useful without
providing way more than you should find time to read. Meanwhile, you
and Scott McPhillips are providing about the feedback I hoped for.

:
Please see my response to Scott McPhillips' note; he raised the same
concern.


My testing has been done on a single core, single CPU system, so none
of this is relevant to the results I've gotten so far. But relevant
anyway, because I do want to make sure my program works on multi
CPU/core systems


More good food for thought.


-----------------------------------------
To reply to me, remove the underscores (_) from my email address (and please indicate which newsgroup and message).

Robert E. Zaret, eMVP
PenFact, Inc.
20 Park Plaza, Suite 400
Boston, MA 02116
www.penfact.com
Useful reading (be sure to read its disclaimer first):
http://catb.org/~esr/faqs/smart-questions.html