Martin Roth (roth++at++ifi.unizh.ch)
Mon, 19 Dec 1994 16:00:36 +0100
I'm in big trouble. If anyone is willing to read the following (lot of)
information, I'd be very glad. I NEED YOUR HELP!!!
I'm building a GIS-application which is capable of changing the scene (i. e.
loading new parts and removing old ones) at run-time. This is done by parallel
loading processes that are sproc'ed from the APP. Further the user interacts
with the application through a GUI built upon the FORMS-library. Because FORMS-
calls may only take place in the DRAW-process, configuration data that:
1. might be changed by the user through the FORMS panels (DRAW)
2. is used within the loading processes (APP)
has to be allocated in shared memory (hasn't it?!).
Up to now I had two big structs allocated in shared memory. Both of them over-
load the new and delete operators in order to do accurate Performer allocation
in shared memory.
struct SharedData {
long example;
...
void *operator new(size_t sz, void *a) {return pfMalloc(sz, a); }
void *operator new(size_t sz) {return pfMalloc(sz, NULL);}
void operator delete(void *addr) {pfFree(addr);}
};
struct CfgData {
long example;
...
void *operator new(size_t sz, void *a) {return pfMalloc(sz, a); }
void *operator new(size_t sz) {return pfMalloc(sz, NULL);}
void operator delete(void *addr) { pfFree(addr);}
};
In the main application two instances of these structs are allocated:
SharedData *shared;
CfgData *cfg;
...
int main (int argc, char **argv) {
void *arena;
pfInit();
arena = pfGetSharedArena();
shared = new(arena) SharedData();
cfg = new(arena) CfgData();
fl_init(); // FORMS initialisation
create_the_forms(); // creation of FORMS panels
... run the application ...
pfExit();
}
Using this version, everything worked fine. Except that it worked extremly
slow. Sometimes it even stuck, without crashing, but nothing went on. The only
explanation of this peculiar loss of speed was the following: Maybe it was
due to the fact that the parallel processes had to access the same structs in
shared memory, running into access conflicts. In this case the Performer
synchronization facility would lock the whole struct when only accessing a
single field.
Fine, I thought, and changed the structs into a lot of normal pointer variables,
allocated in shared memory. Getting a fine granularity seemed a good way to
decrease the probability of running into access conflicts. To stuck with the
example mentioned above, it now looked the following way:
long *shared_example;
...
long *cfg_example;
...
int main (int argc, char **argv) {
void *arena;
pfInit();
arena = pfGetSharedArena();
shared_example = (long *)pfMalloc(sizeof(long), arena);
shared_example = (long *)pfMalloc(sizeof(long), arena);
fl_init(); // FORMS initialisation
create_the_forms(); // creation of FORMS panels
... run the application ...
pfExit();
}
Fine, I thought again, and tried the thing. But the application which hadn't
changed in any significant way just slipped into the Nirwana. I didn't even
get a core dump, segmentation fault, bus error or something like that. The
process just terminated.
Now I started tracing the spot where the application would fail. And I found it
within the fl_init() call. I had the following call stack:
gl_g_winopen(); failure at line 766 in the (gl?!) file mex_window.c
fl_init_colormap(); call to winopen at line 206 in the FORMS file draw.c
fl_init(); call to fl_init_colormap at line 39 in the FORMS
file support.c
That means, my application didn't even make it through the initialization!
Calling fl_init() never was a problem and worked fine till now.
Now, for all those who haven't stopped reading that sad story, my questions:
Does anyone know what is happening to my application?
Does anyone know what things are made on line 766 in "mex_window.c"?
Is it necessary to have that configuration stuff mentioned above in a
shared memory arena or will the draw process (to be exact the FORMS
panels) be able to access the configuration data anyway?
(I tried allocating on the heap, the failure remained the same.)
What exactly has to be in shared memory when using different process
split models?
Does anyone have an other explanation for my application being this slow
when having two big structs in shared memory? If yes, do you have a
remedy?
Thanks for all those who made it through to that spot. Double thanks for all
of you being able to give me some hints.
Martin
_______________________________________________________________________________
/| /|) S. H. Martin Roth
/ |/ |\OTH Student in Computer Science
ETHZ, Swiss Federal Institute of Technology Zuerich email: sroth++at++iiic.ethz.ch
UniZh, University of Zuerich email: roth++at++ifi.unizh.ch
This archive was generated by hypermail 2.0b2 on Mon Aug 10 1998 - 17:50:45 PDT