Click here to Skip to main content
15,881,810 members
Please Sign up or sign in to vote.
0.00/5 (No votes)
See more:
Exactly what is the problem with inheritance in Mutual-threaded application ?
Posted
Comments
Nicholas Butler 4-Jan-12 7:09am    
Inheritance and multi-threading are two unrelated things
Mpho aka Zazo 4-Jan-12 7:26am    
Say then let's have inheritance in an multi-threading application where the object which is shared between threads is design with OOP in mind.
Pantelis Chatzinikolis 4-Jan-12 14:24pm    
Still unrelated. Are you talking about sharing the same object between threads or different instances of the object? Either one, it's still not related to inheritance. Threading issue are generally Run-Time issue and inheritance is a design time issue.
Sergey Alexandrovich Kryukov 4-Jan-12 15:08pm    
Correct. I answered the question in some detail.
--SA
Pantelis Chatzinikolis 4-Jan-12 15:10pm    
Sorry, either it wasn't there when I wrote my comment or I missed it. Great answer.

1 solution

There is no such problem. You can combine both concepts in many different ways as they are not directly related. I would rather say, inheritance (more exactly, OOP), can help multithreading very well. This question lacks subject, really.



For an essential example of use of OOP with multithreading, take a look at my past solutions:
http://www.codeproject.com/Answers/155852/How-to-pass-ref-parameter-to-the-thread#answer2[^],
change paramters of thread (producer) after it started[^].



You can abstract out different aspects of the ThreadWrapper, such as Body by making them virtual function (don't forget to make it protected) and produce several concrete thread wrapper classes sharing the same code, without redundant access to the common fundamental behavior.



As to the problem of sharing of any objects between threads, this problem has nothing to do with OOP; a proper synchronization should be applied to access to any objects, even the primitive ones. Different kind of locks should be used, the simplest one being the lock statement, see: lock Statement (C# Reference).

—SA
 
Share this answer
 
v2
Comments
fjdiewornncalwe 4-Jan-12 14:38pm    
+5. I just fixed a typo.
Sergey Alexandrovich Kryukov 4-Jan-12 15:07pm    
Thank you very much, Marcus.
--SA
Espen Harlinn 4-Jan-12 16:20pm    
5'ed!
Sergey Alexandrovich Kryukov 4-Jan-12 18:38pm    
Thank you, Espen.
--SA
Wendelius 4-Jan-12 17:52pm    
5'ed

This content, along with any associated source code and files, is licensed under The Code Project Open License (CPOL)



CodeProject, 20 Bay Street, 11th Floor Toronto, Ontario, Canada M5J 2N8 +1 (416) 849-8900