|
|
|
Home » Developing U++ » UppHub » "Alternative Multithreading" revisited
 "Alternative Multithreading" revisited [message #22280] |
Mon, 29 June 2009 21:00  |
Mindtraveller
Messages: 917
Registered: August 2007
Location: Russia, Moscow rgn.
|
Experienced Contributor |
|
|
| I'd like to see alternative-MT in the Bazaar[ 13 votes ] |
| 1. |
Yes |
 12 / 92% |
| 2. |
No |
1 / 8% |
Finally I have finished some large U++ application and I have a number of new things tested while writing and debugging it. Currently each of them at release state and I guarantee (almost?) perfect work, although it would be great to have any feedback.
I`d like to introduce first of them here. It is alternative approach to multithreading which was discussed some months ago in this forum. What does it do? Actually it saves lot of your time and eliminates headache of synchronization objects.
Application mentioned above had about 5 threads which were interacting rather actively with each other. And during the months of debugging I didn`t have ANY problems with threads synchronization or something like locks or conflicts. Imagine: 5 threads and no problems!
Of course, this solution has it`s boundaries. It shouldn`t be applied in cases where you have extremely active interaction between threads (actually, more than 300-400 inter-threading "messages"/calls per second on my AMD 2 GHz starts to make difference). In any other cases it is OK to use it.
If you are still interested, let's discuss how to use proposed solution. First of all, it introduces a class/threading model:
- Each thread is an object of CallbackThread class descendant
- Main (GUI) thread is described as the object-descendant of CallbackQueue class (in non-GUI applications you still may have it)
- There are NO public members (it is really OOP-style) and any interaction between threads are made through public member functions
- Each thread (including main) has it`s internal queue of "callbacks" which are executed consequently in FIFO-order. All the functions are executed in object's thread.
That is why you don`t need synchronization objects. Threads interact with some public member functions (delegates/messages) only and they "know" nothing more about each other. So, thread's private functions are executed (handled) in it's own thread and don`t need to do anything with synchronization.
I've added two packages to see and test it. First, MtAlt is the main class to use alternative multithreading. MtAltExample1 is the simple example of it's usage.
Any questions or suggestions are welcome.
-
Attachment: MtAlt.zip
(Size: 4.23KB, Downloaded 595 times)
[Updated on: Mon, 29 June 2009 23:06] Report message to a moderator |
|
|
|
|
|
|
|
| Re: "Alternative Multithreading" revisited [message #22283 is a reply to message #22281] |
Mon, 29 June 2009 23:15  |
Mindtraveller
Messages: 917
Registered: August 2007
Location: Russia, Moscow rgn.
|
Experienced Contributor |
|
|
| gridem wrote on Mon, 29 June 2009 23:51 |
1. But the attached example isn't compiled on Linux platform
2. Why do you use the own callback system instead of Upp callbacks?
|
1. Please try to download archive again from the first post (I`ve reuploaded corrected version) and rebuild.
2. This is good question. I don`t use U++ callbacks because each U++ callback uses system`s synchronization object (link). This makes too big drawback in efficiency in my case. So I use my own implementation, rather small but less universal comparing to U++ ones.
[Updated on: Mon, 29 June 2009 23:32] Report message to a moderator |
|
|
|
|
|
|
|
|
|
| Re: "Alternative Multithreading" revisited [message #25097 is a reply to message #25095] |
Wed, 10 February 2010 10:29 |
Mindtraveller
Messages: 917
Registered: August 2007
Location: Russia, Moscow rgn.
|
Experienced Contributor |
|
|
0. Mt-Alt is more universal.
PostCallback expects callback to be called from main GUI thread. AFAIK, threads without GUI, and non-main threads don't have PostCallback and have no mechanism of queueing callbacks of their own.
Mt-Alt gives queue to any thread you want, including main/GUI and main/non-GUI thread.
So if you have a complex scenario of threads interaction (as I do), you may find useful the simplicity of doing this without any sync objects at all.
1. Mt-Alt is more lightweight.
This is due to avoid using U++ callbacks. In the early periods of Mt-Alt development, I've made a number of tests which finally led me to deny U++ callbacks for potentially-critical-bottleneck class like thread queue.
Each time you create callback, you create system core sync object, use it, and then delete it when callback is destroyed. More of that, operating system may have its own bounds for overall sync objects count.
So, if your system may have high loads and high number of callbacks int the queue, Mt-Alt is much more lightweight and fast.
Current project is being tested with high loads with ~100000 of callbacks in the queue, and it works well.
2. Mt-Alt is more safe and stable.
Everything you call through PostCallback is called in the application "idle" period. This means that if you give too much work for the main GUI thread (or you run your app on rather slow/old PC), it is never idle. And your "new" callbacks are executed with big lag or never executed at all.
The bigger problem connected to one above, is that if you use program for some amount of time, you may have too lengthy internal queue of callbacks. And I don't know if there are any safe ways to guarantee that PostCallback after 2-3 hours of hard CPU work doesn't create exception from callbacks container (old callbacks are still in the queue while you still add new ones).
Mt-Alt proposes two solutions here.
First, mechanism of "pushing old out" if your queue is too big. Also Mt-Alt has ability to call functions from main GUI loop, so you have more adequate behaviour on highly loaded apps and apps which could be installed for slow/old hardware.
I use U++ for hardware automation and operator interface which is commonly used on industrial PCs and even controllers. So I have to optimize and have to be shure that app works well after a pair of months of hard work without switching off or closing my app.
[Updated on: Wed, 10 February 2010 10:33] Report message to a moderator |
|
|
|
| Re: "Alternative Multithreading" revisited [message #25112 is a reply to message #25097] |
Wed, 10 February 2010 22:55 |
|
|
Did you upload the latest version in svn?
Would be nice to have a benchmark!
Regards, Ion Lupascu(tojocky)
| Mindtraveller wrote on Wed, 10 February 2010 11:29 |
0. Mt-Alt is more universal.
PostCallback expects callback to be called from main GUI thread. AFAIK, threads without GUI, and non-main threads don't have PostCallback and have no mechanism of queueing callbacks of their own.
Mt-Alt gives queue to any thread you want, including main/GUI and main/non-GUI thread.
So if you have a complex scenario of threads interaction (as I do), you may find useful the simplicity of doing this without any sync objects at all.
1. Mt-Alt is more lightweight.
This is due to avoid using U++ callbacks. In the early periods of Mt-Alt development, I've made a number of tests which finally led me to deny U++ callbacks for potentially-critical-bottleneck class like thread queue.
Each time you create callback, you create system core sync object, use it, and then delete it when callback is destroyed. More of that, operating system may have its own bounds for overall sync objects count.
So, if your system may have high loads and high number of callbacks int the queue, Mt-Alt is much more lightweight and fast.
Current project is being tested with high loads with ~100000 of callbacks in the queue, and it works well.
2. Mt-Alt is more safe and stable.
Everything you call through PostCallback is called in the application "idle" period. This means that if you give too much work for the main GUI thread (or you run your app on rather slow/old PC), it is never idle. And your "new" callbacks are executed with big lag or never executed at all.
The bigger problem connected to one above, is that if you use program for some amount of time, you may have too lengthy internal queue of callbacks. And I don't know if there are any safe ways to guarantee that PostCallback after 2-3 hours of hard CPU work doesn't create exception from callbacks container (old callbacks are still in the queue while you still add new ones).
Mt-Alt proposes two solutions here.
First, mechanism of "pushing old out" if your queue is too big. Also Mt-Alt has ability to call functions from main GUI loop, so you have more adequate behaviour on highly loaded apps and apps which could be installed for slow/old hardware.
I use U++ for hardware automation and operator interface which is commonly used on industrial PCs and even controllers. So I have to optimize and have to be shure that app works well after a pair of months of hard work without switching off or closing my app.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Goto Forum:
Current Time: Tue Jan 14 15:07:47 CET 2025
Total time taken to generate the page: 0.03101 seconds
|
|
|
Members
Pages
Help
Register
Login
Home
