Overview
Examples
Screenshots
Comparisons
Applications
Download
Documentation
Tutorials
Bazaar
Status & Roadmap
FAQ
Authors & License
Forums
Funding Ultimate++
Search on this site
Search in forums












SourceForge.net Logo
Home » Developing U++ » UppHub » "Alternative Multithreading" revisited
icon3.gif  "Alternative Multithreading" revisited [message #22280] Mon, 29 June 2009 21:00 Go to next message
Mindtraveller is currently offline  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 553 times)

[Updated on: Mon, 29 June 2009 23:06]

Report message to a moderator

Re: "Alternative Multithreading" revisited [message #22281 is a reply to message #22280] Mon, 29 June 2009 21:51 Go to previous messageGo to next message
gridem is currently offline  gridem
Messages: 45
Registered: August 2008
Member
The idea is very interesting. But the attached example isn't compiled on Linux platform:

----- CtrlLib ( GUI MT GCC DEBUG SHARED DEBUG_FULL BLITZ LINUX POSIX ) (1 / 10)
----- MtAlt ( GUI MT GCC DEBUG SHARED DEBUG_FULL BLITZ LINUX POSIX ) (2 / 10)
WARNING: /home/grigory/MyApps/MtAlt/MtAlt.cpp has invalid (future) time 06/29/2009 18:32:40
WARNING: /home/grigory/MyApps/MtAlt/MtAlt.h has invalid (future) time 06/29/2009 20:04:58
MtAlt.cpp
/home/grigory/MyApps/MtAlt/MtAlt.cpp: In function 'Upp::dword rdtsc()':
/home/grigory/MyApps/MtAlt/MtAlt.cpp:9: error: expected `(' before '{' token
/home/grigory/MyApps/MtAlt/MtAlt.cpp:11: error: expected `;' before 'mov'

*** 2 errors, 0 warnings
MtAlt: 1 file(s) built in (0:04.69), 4692 msecs / file, duration = 4723 msecs

There were errors. (0:06.22)


And one more question:
Why do you use the own callback system instead of Upp callbacks?

Thank you for your tempting MT GUI approach.
Re: "Alternative Multithreading" revisited [message #22282 is a reply to message #22280] Mon, 29 June 2009 22:15 Go to previous messageGo to next message
mirek is currently offline  mirek
Messages: 13975
Registered: November 2005
Ultimate Member
Mindtraveller wrote on Mon, 29 June 2009 15:00



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.




Well, I have some experiences now (did project based on queues, now planning to rewrite it to plain old locking) and I have something to say about the topic (IMO!):

Synchronization objects are simple to manage as compared to often complex race condition relations in queued systems.

IMO, this is the exactly same problem that seems to have killed microkernels.

Mirek
Re: "Alternative Multithreading" revisited [message #22283 is a reply to message #22281] Mon, 29 June 2009 23:15 Go to previous messageGo to next message
Mindtraveller is currently offline  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 #22284 is a reply to message #22282] Mon, 29 June 2009 23:53 Go to previous messageGo to next message
Mindtraveller is currently offline  Mindtraveller
Messages: 917
Registered: August 2007
Location: Russia, Moscow rgn.
Experienced Contributor

luzr wrote on Tue, 30 June 2009 00:15

1. did project based on queues, now planning to rewrite it to plain old locking
2. Synchronization objects are simple to manage as compared to often complex race condition relations in queued systems.
3. IMO, this is the exactly same problem that seems to have killed microkernels.

1. Mirek, this is very interesting why you decided to switch back to "classic-MT". Could we discuss it in the old topic? I've written that this approach has it`s boundaries, and it could be you jast had that case.
2. As I remember debugging app with 3+ threads and classic sync. objects - this was complete hell.
3. This is interesting too and I'd like to discuss it in the same topic. Microkernel is certainly very specific program with very strong requirements in efficiency, memory and overhead. Of course it should handle hundreds of thousands of messages per second. Alternative-MT is closer to classic GUI apps where you shouldn`t quickly handle large masses of data between threads. The same is for some types of internet server applications. In the other hand, most typical applications use 10-100 events per second and it is OK for alt-MT.
Re: "Alternative Multithreading" revisited [message #25087 is a reply to message #22280] Tue, 09 February 2010 23:37 Go to previous messageGo to next message
Mindtraveller is currently offline  Mindtraveller
Messages: 917
Registered: August 2007
Location: Russia, Moscow rgn.
Experienced Contributor

Did anyone try to use MTAlt? Or it is useless for everyone? Or should I post detailed help about these classes?

P.S. I'd like to update a file in the SVN: /bazaar/MtAlt/MtAlt.h. Please do it someone who has access to bazaar sources.
  • Attachment: MtAlt.h
    (Size: 8.21KB, Downloaded 427 times)
Re: "Alternative Multithreading" revisited [message #25095 is a reply to message #25087] Wed, 10 February 2010 09:29 Go to previous messageGo to next message
koldo is currently offline  koldo
Messages: 3355
Registered: August 2008
Senior Veteran
Hello Mindtraveller

Now I use Upp MT using PostCallback(). From user side I understand how to use it and it works well in MinGW. It lets tenths of threads acting simultaneously over the Gui in the main thread.

From this point of view, what are the advantages of Alt-MT ?


Best regards
Iñaki
Re: "Alternative Multithreading" revisited [message #25097 is a reply to message #25095] Wed, 10 February 2010 10:29 Go to previous messageGo to next message
Mindtraveller is currently offline  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 Go to previous messageGo to next message
tojocky is currently offline  tojocky
Messages: 607
Registered: April 2008
Location: UK
Contributor

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.

Re: "Alternative Multithreading" revisited [message #25115 is a reply to message #25087] Thu, 11 February 2010 08:15 Go to previous messageGo to next message
koldo is currently offline  koldo
Messages: 3355
Registered: August 2008
Senior Veteran
Mindtraveller wrote on Tue, 09 February 2010 23:37

Did anyone try to use MTAlt? Or it is useless for everyone? Or should I post detailed help about these classes?

P.S. I'd like to update a file in the SVN: /bazaar/MtAlt/MtAlt.h. Please do it someone who has access to bazaar sources.

Hello Pavel

If you think your work is useful, follow developing it, improving the example and adding help.

Sometimes people is shy and do not give you feedback so you finally think nobody is using it. Smile



Best regards
Iñaki
Re: "Alternative Multithreading" revisited [message #26728 is a reply to message #25115] Fri, 21 May 2010 23:23 Go to previous messageGo to next message
Mindtraveller is currently offline  Mindtraveller
Messages: 917
Registered: August 2007
Location: Russia, Moscow rgn.
Experienced Contributor

Please upload new version of MtAlt.

Added support for fast 5-argument callbacks (copy and pick version).

Planned: Priority thread queue. (Mirek, I've invented how to evade explicit Mutex / second queue issue - if you remember our discussion Smile ).
  • Attachment: MtAlt.zip
    (Size: 1.95KB, Downloaded 437 times)
Re: "Alternative Multithreading" revisited [message #32090 is a reply to message #26728] Thu, 21 April 2011 14:29 Go to previous messageGo to next message
Mindtraveller is currently offline  Mindtraveller
Messages: 917
Registered: August 2007
Location: Russia, Moscow rgn.
Experienced Contributor

I guess noone is using CallbackThread classes except me. May be it is good idea to remove this package from official Bazaar.
Re: "Alternative Multithreading" revisited [message #32092 is a reply to message #32090] Thu, 21 April 2011 16:35 Go to previous messageGo to next message
zsolt is currently offline  zsolt
Messages: 693
Registered: December 2005
Location: Budapest, Hungary
Contributor
Mindtraveller wrote on Thu, 21 April 2011 14:29

May be it is good idea to remove this package from official Bazaar.

I don't think so. I have learned a lot from that. And it would be useful in embedded systems, I think.

Please, don't remove it.
Re: "Alternative Multithreading" revisited [message #32105 is a reply to message #32092] Sun, 24 April 2011 18:31 Go to previous message
koldo is currently offline  koldo
Messages: 3355
Registered: August 2008
Senior Veteran
Hello Konstantin

I have the same opinion.

IMHO:
- if you think your package is valuable for U++ users (or at least is better than other packages inside Bazaar Smile)

- and you will maintain it.

Bazaar will be glad to host your Package Smile.


Best regards
Iñaki
Previous Topic: PythonPP - tiny C++ wrappers for Python C API
Next Topic: Urr
Goto Forum:
  


Current Time: Fri Mar 29 07:06:57 CET 2024

Total time taken to generate the page: 0.01773 seconds