Re: pthreads and c++ destructor -- C400-L

Thanks for all your help, i will check those documents, im pretty sure that is a application problem as you said.
I come from x86 world where there arent many memory management options. It's so confusing haha.
I change my storage model to Teraspace and the MCH6902 stopped for now, although i have to do more exhaustive testing in case the error show up again.

T Hanks again

To: c400-l@xxxxxxxxxxxx
From: albertaa@xxxxxxxxxx
Date: Wed, 6 Oct 2010 17:13:14 -0500
Subject: Re: [C400-L] pthreads and c++ destructor

Hi,

My apologies, I was looking for the lock at the point where the arrays were
modified/read, so I missed the comments in the functions.

The new and delete routines are thread safe, so it is probably not a thread
or timing issue in the C++ Runtime. It is more likely to be an application
problem. Unfortunately, this type of problem can be very difficult to
track down. Here are a couple of resources I would recommend:

1. The "ILE C/C++ Runtime Library Functions" manual in infocenter
(http://publib.boulder.ibm.com/infocenter/iseries/v7r1m0/index.jsp). Pay
particular attention to the "Diagnosing C2M1211/C2M1212 Message Problems"
article near the end of the "Runtime Considerations" chapter. This is a
7.1 manual, but the methods discussed are valid on 6.1 as well. Some of
the methods discussed are valid on older releases
2. The "Mastering ILE Heap Memory Management" article by Scott Hanson
(http://systeminetwork.com/article/mastering-ile-heap-memory-management).
Near the end of this article is a nice in-depth discussion of the debug
memory manager facility introduced in IBM i 6.1.

You can also use PEX (Performance Explorer) to look at the problem. Here
is a command you can use to create the appropriate PEX definition:

ADDPEXDFN DFN(<choose name>) TYPE(*TRACE) JOB(<specify job>) TRCTYPE
(*SLTEVT) SLTEVT(*YES) STGEVT((*ACTGRPHEAP))

Note: The above definition will not work if you are using teraspace
storage. If you are you will need to specify the *CLEHEAP event instead:
STGEVT((*CLEHEAP *NONE *FORMAT2)).

Aaron Albertson

c400-l-bounces+albertaa=us.ibm.com@xxxxxxxxxxxx wrote on 10/06/2010
12:42:37 PM:

From: Victor Gonzalez <victorpy@xxxxxxxxxxx>
To: <c400-l@xxxxxxxxxxxx>
Date: 10/06/2010 12:43 PM
Subject: Re: [C400-L] pthreads and c++ destructor
Sent by: c400-l-bounces+albertaa=us.ibm.com@xxxxxxxxxxxx

Thanks for your help

I know about the lock in threads, that's why i put the comment one
line before accessing the function. I forgot to put the lock in the
working example thou, i think that's why you tell me about the concept.
That was a problem solved thanks to you, but now i have another question.
Obviously my application is more sophisticated than the example i
shown. Doing some debug in my application i found something that is
very rare, it could be me or some memory compile option in the AS/
400. Let me put some debug output.

This line is a print after i made a "new" assignment, it returns
this pointer value
[06-10-2010 15:02:10.818360]ServerTransaction() client 80000000 0
f1b4f178 5625bca0

Then after 10 seconds i "delete" the memory for the assignment.
[06-10-2010 15:02:20.850216]ServerTransaction() clientStateArray[i]
80000000 0 f1b4f178 5625bca0

In another thread, a do again a "new" assignment giving me this the
same address as before
[06-10-2010 15:02:20.921320]ServerTransaction() client 80000000 0
f1b4f178 5625bca0

Then the problems come when i try to "delete" the assingment after
10 seconds again, i get a MCH6902, then the message C2M1212. The
last message say "Reason code X'10000000'" and the address shown is
X'8000000000000000F1B4F1785625BCA0', the same i try to delete
[06-10-2010 15:02:30.942872]ServerTransaction() clientStateArray[i]
80000000 0 f1b4f178 5625bca0

My question is, could it be affecting in someway that the address is
deleted and then return by new in less than 71 milliseconds? So the
memory manager still put that address as delete or not assigned

again, thanks for the help

To: c400-l@xxxxxxxxxxxx
From: albertaa@xxxxxxxxxx
Date: Tue, 5 Oct 2010 09:50:41 -0500
Subject: Re: [C400-L] pthreads and c++ destructor

Hi Victor,

You're violating one of the fundamental concepts of threaded
programming here. Any time you modify static data within a thread and

that

data could be accessed from another thread you will need to use some

sort

of locking routine to guarantee that only one of the threads has access

to

the static data at any given time.

For now, lets ignore the 1/2 second sleep. At the end of the loop
you create a thread which calls the ReadArray function. Then at the
beginning of the loop you call the ModifyArray function. It is likely

that

ReadArray is still running in it's thread, and you could end up

modifying

the array while you are trying to read it (thus the bogus values).

Even the 1/2 second sleep is no guarantee. If the system is busy it
is possible that the ModifyArray thread may not have finished by the

time

the ReadArray function runs.

If you use locking (I think the pthread lock function is something
like pthread_mutex_lock) you should be able to avoid these problems and
avoid the use of the sleep routine altogether. Also keep in mind that

it's

possible that you'll have several (more than two) threads running at

once,

so if you care about the order of reads and writes you'll need to add a
little more logic to your functions to enforce ordering.

Thanks,

Aaron Albertson

c400-l-bounces+albertaa=us.ibm.com@xxxxxxxxxxxx wrote on 10/05/2010
09:04:51 AM:

From: Victor Gonzalez <victorpy@xxxxxxxxxxx>
To: <c400-l@xxxxxxxxxxxx>
Date: 10/05/2010 09:09 AM
Subject: Re: [C400-L] pthreads and c++ destructor
Sent by: c400-l-bounces+albertaa=us.ibm.com@xxxxxxxxxxxx

here i post a working code, if anyone could compile it and try. In
my previous mail i forgot to put the delete line in the Read function

#define _MULTI_THREADED
#include <iostream>
#include <pthread.h>
#include <unistd.h>
#include <stdio.h>

using namespace std;

class MyClass
{

char **myCharArray;

public:

void ModifyArray()

{
myCharArray = new char*[10];

for(int i = 0; i < 10; i++)
{
myCharArray[i] = new char[20];
sprintf(myCharArray[i], "%s%i", "mod ", i);

}

}

void ReadArray()
{
for(int i = 0; i < 10; i++)
{
cout << "element " << i << " "<<myCharArray[i]<<endl;
delete [] myCharArray[i];
}

}

};

MyClass *g_myclass;

void *ModClass(void *parm)
{
//mutex lock not shown
g_myclass->ModifyArray();

return NULL;
}

void *ReadClass(void *parm)
{
//mutex lock not shown
g_myclass->ReadArray();

return NULL;
}

int main()
{

int i = 0, rc;
pthread_t thread1, thread2;

g_myclass = new MyClass();

while(i < 1000)
{

//thread api not used, just pseudo-code
//1)
//createThread(ModClass);
rc = pthread_create(&thread1, NULL, ModClass, NULL);

//sleep(1)
usleep(500000);
//2)
rc = pthread_create(&thread2, NULL, ReadClass, NULL);

i++;

}

}

From: victorpy@xxxxxxxxxxx
To: c400-l@xxxxxxxxxxxx
Date: Tue, 5 Oct 2010 13:28:07 +0000
Subject: [C400-L] pthreads and c++ destructor

Hello to all,

I think im having a problem with threads and c++ destructor. I'll

explain the problem

Supose i have a Class myclass that is global for all threads. A

thread is created modify some attributes of the class then
terminates. All the threads that modifies the class are detached.

After some time i try to access the modified attribute of the

class, but this no longer have the value i put in the first thread.
i.e. the value is gone or is trash.

Let me put a practical example

Class MyClass
{

char **myCharArray;

void ModifyArray()

{
myCharArray = new char*[10];

for(int i = 0; i < 10; i++)
myCharArray[i] = new char[20];
}

char ReadArray()
{
for(int i = 0; i < 10; i++)
cout << "element " << i << " "<<myCharArray[i]<<endl;

}

};

void *ModClass(void *parm)
{
//mutex lock not shown
g_myclass->ModifyArray();
}

void *ReadClass(void *parm)

{

//mutex lock not shown

g_myclass->ReadArray();

}

MyClass *g_myclass

int main()
{

int i = 0

g_myclass = new MyClass();

while(i < 10)
{

//thread api not used, just pseudo-code
//1)
createThread(ModClass);

sleep(10)
//2)
createThread(ReadClass);

i++;

}

}

1) In the first thread the array is modified using new operator,

after that the thread is detached.

2) After some period of time the array is accessed for read, but

in some cases after various iteration, the element in the array is

gone.

Could it be that the modification of the array with new in the

thread is deleted after the execution of the thread?. I think it
could be that because i read about thread releasing resources after

detaching

Any help will be welcome

Thanks

--
This is the C programming iSeries / AS400 (C400-L) mailing list
To post a message email: C400-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/c400-l
or email: C400-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/c400-l.

--
This is the C programming iSeries / AS400 (C400-L) mailing list
To post a message email: C400-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/c400-l
or email: C400-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/c400-l.

--
This is the C programming iSeries / AS400 (C400-L) mailing list
To post a message email: C400-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/c400-l
or email: C400-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/c400-l.

--
This is the C programming iSeries / AS400 (C400-L) mailing list
To post a message email: C400-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/c400-l
or email: C400-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/c400-l.

--
This is the C programming iSeries / AS400 (C400-L) mailing list
To post a message email: C400-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/c400-l
or email: C400-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/c400-l.