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 » Community » Coffee corner » Sharing and Locking
Re: Sharing and Locking [message #25831 is a reply to message #25824] Sun, 14 March 2010 18:58 Go to previous messageGo to previous message
mirek is currently offline  mirek
Messages: 14255
Registered: November 2005
Ultimate Member
gridem wrote on Sun, 14 March 2010 08:37

The above approach has objects on the heap instead of stack but it has predictable object lifetime. I think that it's the reasonable overhead to solve the considered race condition in case of object destroying.

Mirek, what do you think?


I am still not quite sure what you are trying to solve:)

What I think you are trying to do is to avoid dangling pointer. Anyway, making pointer itself dangling helps only a bit and perhaps is not a good strategy: Pointer itself can still exist, but the state of object can be "destroyed". So it may seal some references to it, but IMO is not a good way.

Now maybe my experiences are not wide enough, but I belive that so far, I had little problems with race conditions of this kind in MT code. I guess, usually the best is to make things simple and not get involved into any shared ownership, which after all is the cornerstone of U++ design.
 
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
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Previous Topic: Windows 7 - long wait after app crash
Next Topic: Upp application and CPU on Linux
Goto Forum:
  


Current Time: Sun Apr 27 08:15:34 CEST 2025

Total time taken to generate the page: 0.03977 seconds