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

[Ed C. <em...@ed...>]

Per, Santiago, & Reid -

Thanks for your help! I ended up assigning memory from the main thread
(since the RTL was not thread-safe). Once I did that and cleaned up a =
bunch
of excessive pointer use (I was passing too many arguments to the thread
routine as pointers), it worked perfectly: no thread lock-ups, and I'm
actually getting the maximum possible throughput on my DSL connection.

That's thanks in no small part to those on this list. Thank you! Without =
the
help of this group, I would be struggling for many hours to come.

-Ed


-----Original Message-----
From: dev...@li...
[mailto:dev...@li...] On Behalf Of Per
Westermark
Sent: Wednesday, September 17, 2003 3:21 PM
To: Ed Cottrell
Cc: dev...@li...
Subject: RE: [Dev-C++] Multi-Threading locks up


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=20
> first multi-threaded app in a language without a garbage collector /=20
> built-in memory management (like Java).
>
> So, does this mean I need to allocate all memory for the threads from=20
> 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=20
> main thread and only let one thread access it. Is that what you're=20
> saying?
>
> -Ed
>
> P.S. How would I do the memory locking you describe, under Win32? I'm=20
> plenty familiar with the concept, but don't know how to implement it=20
> 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=20
> 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=20
> allocates memory new/malloc/calloc will break if not thread-safe. The=20
> 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,=20
> dynamically allocated or indexed into an array - one entry for each=20
> thread.
>
> 3 - If you have to access the same global variable from the different=20
> threads, or for a child thread and the main thread, you have to=20
> 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=20
> > multiple databases and does data-mining. The main thread (which=20
> > includes the Win32
> > GUI) launches off a user-specified number of threads (say, 10),=20
> > which then do the actually database queries.
> >
> > I've hit a weird snag, though. As written, the threads all start=20
> > properly, but then pause themselves, immediately, or almost=20
> > immediately (after updating 0 to maybe 500 records, out of several=20
> > hundred thousand). The problem isn't on the database server end; it=20
> > works fine, but reports that the threads have stopped running=20
> > queries.
> > Pseudo-code:
> >
> > ...
> > int i, MyThreads=3D10;
> > for(i =3D 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=20
> > threads start properly AND run until finished! Pseudo-code:
> >
> > ...
> > int i, MyThreads=3D10;
> > char mymsg[10]
> > for(i =3D 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.=20
> > 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=20
> _______________________________________________
> 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
>



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