Diese Seite mit anderen teilen ...

Informationen zum Thema:
Forum:
WinDev Forum
Beiträge im Thema:
7
Erster Beitrag:
vor 4 Jahren, 11 Monaten
Letzter Beitrag:
vor 4 Jahren, 11 Monaten
Beteiligte Autoren:
JP, Fabrice Harari, GuenterP

[WD18] - Using multiple threads

Startbeitrag von JP am 18.09.2013 12:17

Hi All,

I have a design question and looking for some advice from the WD experts. I have an application that allows the user to open multiple windows. These windows can contain tables or charts or whatever. The data for some of these windows can change from time to time and I wish to update those windows on a regular basis if new data is available. I can think of two ways using threads:

1) Option 1 - have a single application wide thread that monitors for new data and updates the relevant windows that need it.

2) Option 2 - let each window have its own thread which handles the data relevant to just that window and nothing else.

The threads are not very resource heavy. They will look for new data once every 5 seconds or 10 seconds or so. If they find some data then the process to retrieve it and update a window is quite fast.

I want to use threads because I want the user to be free to use the rest of the application as they like. The updates can happen in the background. Both options have pros and cons.

Question: is there any problem to have multiple threads working in this way? 5 threads? 10 threads? 50 threads? Is there a point at which too many threads presents a performance issue and a single global thread would be the best way?

Any thoughts/suggestions?

Thanks.

Antworten:

Hi JP

Yes, there is a limit to the number of concurrent thread, and it depends on the machine capacities and the load of your threads.

I would personnaly apply the KISS principle and use ONE global thread to prepare the data for all windows... You will need to have the data refreshed in each window by its main thread anyway

Best regards

von Fabrice Harari - am 18.09.2013 12:35
Hi JP,

look into RAD11 Table type Windows. They have a full built-in data refresh management for a multi-user environment. Even if you don't use RAD11 (which I'm still doing) then you just could pinch the code and the basic ideas from there.

von GuenterP - am 18.09.2013 13:40
Hi Fabrice,

This is actually how I programmed it already but was looking for confirmation that this was indeed the better approach - thanks. On the related topic - is setting each window to keep its own HyperFile Context a good idea or should the procedures of the window ensure the correct context and record positions? In other words, let WD handle the context or manually make sure it is correct at a procedure level?

I assume letting WD handle it will incur a resource consumption since each window will need its own context stored somewhere, y/n? On the other hand, there is something to be said for letting WD do the work rather than progrmaming it all yourself. What do you think?

von JP - am 18.09.2013 13:41
Thanks Guenter, I have it working using the single global thread model. It works well enough for the purpose at hand. Thanks again.

von JP - am 18.09.2013 17:08
Hi JP

I do not have any definite answer to the HF context question. For me it really depends on the applicaiton, and I do not think that keeping independant contexts is going to cost anything measurable in ressources...

Now if you are using a GLOBAL procedure/thread to update ALL the windows, then it looks to me that the independant context option is out of the window. In this case, I would personnaly rely either on data loaded in memory tables or in queries specific to each window

But I'm a big believer in the "whatever works for your specific problem" approach, and I do not have enough information on your requirements to be able to jusdge here

Best regards

von Fabrice Harari - am 18.09.2013 19:29
Thanks Fabrice.

von JP - am 19.09.2013 06:06
Zur Information:
MySnip.de hat keinen Einfluss auf die Inhalte der Beiträge. Bitte kontaktieren Sie den Administrator des Forums bei Problemen oder Löschforderungen über die Kontaktseite.
Falls die Kontaktaufnahme mit dem Administrator des Forums fehlschlägt, kontaktieren Sie uns bitte über die in unserem Impressum angegebenen Daten.