Re: Is threading the right solution for this challenge?

"Chris" <ctaliercio@xxxxxxxxx> wrote in message news:1146769621.763307.155120@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
Thanks Oliver - I appreciate the feedback.

The problem I am facing is that it is a complex routing that is called
in order to refresh the screen. There are several tables in an Oracle
database that need to be interrogated, several OS processes that need
to be examined, etc. A typical screen "refresh" could take up to 10-15
seconds.

I didn't want the user to have to wait 10-15 seconds between their
input and the application's reaction to it. That is why I was leaning
toward threads. I understand that there can be some overlapping of
memory resources, and some unexpected results if you are not careful in
your coding, but I believe MF gives me a way out of that mess with the
THREAD-LOCAL-STORAGE section.

What I was envisioning was the main program spawning two threads - one
that continually updates the display, and the other that simply
accepts/reacts to user input. If the user chose to exit, I could kill
the display thread (since it is only inquiring there is no danger
there) and have the application exit immediately.

To get the same type behavior in a single program, I'd need to have the
loop that is collecting information to update the display continuously
interrupt itself to check for user input and react to it. That didn't
seem like the most efficient way for me to accomplish what I am looking
to do.

I'm assuming that the displaying thread will just do its query and display the results, without ever affecting the user input thread. Is there anything that the user input thread could do that would directly affect the displaying thread? For example if the user input thread changes some records in the Oracle DB, presumably the DB will take care of its own concurrency locking issues, and the input thread won't directly, for example, edit the variables within the displaying thread. Rather they will communicate to each other only with the Oracle DB acting as a middle man.

If so, you might be able to avoid all the pitfalls that are typically present in multithreaded programming. If you're working on a line oriented system though, have you tried writing a simple mock up program to ensure that it's possible to have two threads, one performing a DISPLAY and one performing an ACCEPT on the same terminal at the same time?

- Oliver

.