U++ framework
Do not panic. Ask here before giving up.

Home » Developing U++ » UppHub » "Alternative Multithreading" revisited
Re: "Alternative Multithreading" revisited [message #22282 is a reply to message #22280] Mon, 29 June 2009 22:15 Go to previous messageGo to previous message
mirek is currently offline  mirek
Messages: 14291
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
 
Read Message icon3.gif
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Previous Topic: PythonPP - tiny C++ wrappers for Python C API
Next Topic: Urr
Goto Forum:
  


Current Time: Thu May 14 15:02:25 GMT+2 2026

Total time taken to generate the page: 0.00830 seconds