RE: [Dev-C++] Multi-Threading locks up

[Per W. <pw...@ia...>]

No, I didn't say it is forbidden to allocate memory in the individual
threads. It's just that you must make sure that the RTL is multi-thread
safe.

Correct me someone, but for MinGW you have to specify -mthreads to the
linker when you build the project.

new/malloc/calloc are not the only RTL functions that may fail in a
multithreaded app. The random generator, and a number of date/time
functions etc are using static variables and buffers and may because of
that fail spectacularly.

If you build on an environment when the compiler can't supply a
thread-safe RTL, then you must manually protect any calls to RTL functions
that might use static state information.

/Per W

On Wed, 17 Sep 2003, Ed Cottrell wrote:

> Per,
>
> It seems like that's probably the root of my problem... This is my first
> multi-threaded app in a language without a garbage collector / built-in
> memory management (like Java).
>
> So, does this mean I need to allocate all memory for the threads from within
> the main thread? For example, one of the thread-level variables for each
> thread is a memory buffer of 50k for batching SQL statements. If I
> understand you, then, I need to allocate that memory from the main thread
> and only let one thread access it. Is that what you're saying?
>
> -Ed
>
> P.S. How would I do the memory locking you describe, under Win32? I'm plenty
> familiar with the concept, but don't know how to implement it in C.
>
>
> -----Original Message-----
> From: Per Westermark [mailto:pw...@ia...]
> Sent: Wednesday, September 17, 2003 1:48 PM
> To: Ed Cottrell
> Cc: dev...@li...
> Subject: Re: [Dev-C++] Multi-Threading locks up
>
>
> I think you have a problem with shared memory. While each new thread shares
> the same memory space with the parent, they should - must - not access the
> same memory at the same time.
>
> 1 - are you linking with a thread-safe RTL, i.e. if the threads allocates
> memory new/malloc/calloc will break if not thread-safe. The same goes for
> the calls to open the connection to the database.
>
> 2 -  All memory used in the threads should either be on the stack,
> dynamically allocated or indexed into an array - one entry for each thread.
>
> 3 - If you have to access the same global variable from the different
> threads, or for a child thread and the main thread, you have to protect the
> access with a critical section, mutex, spinlock or similar to assert
> serialized access.
>
> /Per W
>
> On Wed, 17 Sep 2003, Ed Cottrell wrote:
>
> > Hi,
> >
> > I'm working on a multi-threaded database app, which connects to
> > multiple databases and does data-mining. The main thread (which
> > includes the Win32
> > GUI) launches off a user-specified number of threads (say, 10), which then
> > do the actually database queries.
> >
> > I've hit a weird snag, though. As written, the threads all start
> > properly, but then pause themselves, immediately, or almost
> > immediately (after updating 0 to maybe 500 records, out of several
> > hundred thousand). The problem isn't on the database server end; it
> > works fine, but reports that the threads have stopped running queries.
> > Pseudo-code:
> >
> > ...
> > int i, MyThreads=10;
> > for(i = 0; i < MyThreads; i++)
> >     {
> >         //Splits up the work, here, into MyThreads chunks
> >         _beginthread( [the arguments] )
> >     }
> > ...
> >
> > This is where it gets weird... IF I create a message box first, the
> > threads start properly AND run until finished! Pseudo-code:
> >
> > ...
> > int i, MyThreads=10;
> > char mymsg[10]
> > for(i = 0; i < MyThreads; i++)
> >     {
> >         //Splits up the work, here, into MyThreads chunks
> >         _beginthread( [the arguments] )
> >         sprintf(mymsg, "%d", i);
> >         MessageBox(0, mymsg, mymsg, MB_OK);
> >     }
> > ...
> >
> > The ONLY difference is in whether or not I show a message box. Anybody
> > know what that's about? Thanks a million!
> >
> > -Ed
> >
> >
>
>
>
>
>
> -------------------------------------------------------
> This sf.net email is sponsored by:ThinkGeek
> Welcome to geek heaven.
> http://thinkgeek.com/sf
> _______________________________________________
> Dev-cpp-users mailing list
> Dev...@li...
> TO UNSUBSCRIBE: http://www23.brinkster.com/noicys/devcpp/ub.htm
> https://lists.sourceforge.net/lists/listinfo/dev-cpp-users
>