FreeAndNil() - The Great Delphi Developer Debate

[Attila Kovacs 629]

What interface references and automatic memory managed instances allow you to do is to have multiple, unshared, references to
a shared object instance. And as long as some of those references is alive, that object instance will be alive and valid, too.

But this is a different program as freeing randomly shared objects (Beginning of the story). You can do the same with a shared counter and atomic inc/dec without interfaces.

Not to mention, that re-referencing that interface (creating new unshared references) has to be made in a tricky way, creating first a new, temporary reference to be sure its refcnt won't reach 0 at the same time.

 

I'm also not sure, what this has to do with FreeAndNil(). Looks like somebody wanted to take a shortcut but did not work out and culprit is the language?

 

 

 

[Dalija Prasnikar 1398]

8 hours ago, Attila Kovacs said:

What interface references and automatic memory managed instances allow you to do is to have multiple, unshared, references to
a shared object instance. And as long as some of those references is alive, that object instance will be alive and valid, too.

But this is a different program as freeing randomly shared objects (Beginning of the story). You can do the same with a shared counter and atomic inc/dec without interfaces.

Not to mention, that re-referencing that interface (creating new unshared references) has to be made in a tricky way, creating first a new, temporary reference to be sure its refcnt won't reach 0 at the same time.

 

Yes, it is a different "program". as automatic memory management requires not only changes in class declarations, but also in how they are used. fixing existing code and making it thread-safe, requires locking mechanism. There are other ways to ensure that the reference is valid while it is being used, but shared counter and atomic increments and decrements are not sufficient to achieve that.

 

I mentioned interfaces, because automatic memory management allows different approach to a problem, and in some scenarios leads to simpler and more maintainable code, that does not require locking mechanisms that blocks other threads. Whether such approach is viable in particular scenario is another question, but we were not talking about exact code and without exact code you can only talk in very broad and general terms.

 

When creating new reference, you don't do that from the background thread, you take existing strong reference and assign it to another one from the context of a thread that holds that strong reference so it cannot become invalid while you are assigning it to another reference. Then you pass that new reference to a new thread. As long as you have strong reference that will not be niled by any other thread, you can safely create new ones from that one. What you cannot do is assigning and nilling the same reference from different threads. No need for any kind of tricks. 

 

Another solution for initial problem, would be not calling FreeAndNil from any thread and waiting for all threads to finish before instance is released. But again, without knowing exact code, it is hard to say what is the best and proper solution.

 

8 hours ago, Attila Kovacs said:

I'm also not sure, what this has to do with FreeAndNil(). Looks like somebody wanted to take a shortcut but did not work out and culprit is the language?

I am not sure what you mean with the last sentence.

[Attila Kovacs 629]

2 hours ago, Dalija Prasnikar said:

When creating new reference, you don't do that from the background thread, you take existing strong reference and assign it to another one from the context of a thread that holds that strong reference so it cannot become invalid while you are assigning

If you have such a strong reference, you don't need the whole hocus-pocus. It will be the point where the object should be released regardless of whether it's an interface or not.

2 hours ago, Dalija Prasnikar said:

I am not sure what you mean with the last sentence.

I mean, the idea using FreeAndNil instead of locking.

[Dalija Prasnikar 1398]

10 minutes ago, Attila Kovacs said:

If you have such a strong reference, you don't need the whole hocus-pocus. It will be the point where the object should be released regardless of whether it's an interface or not.

Of course. If the reference and the object is valid longer than the threads using such object, then there is no problem. But there is no need for FreeAndNil then, too.  Nor locking.

 

But that only works if that specific point can be moved outside threads or if you can use locking mechanism within threads. I am saying "can use locking" because locking is not always viable solution. You might have situation where such point is not fixed, and shared object instance through multiple interface references may be better choice as the object is valid as long as some thread is using it and you don't need to use locks.

 

16 minutes ago, Attila Kovacs said:

I mean, the idea using FreeAndNil instead of locking.

Obviously it is developer's fault for using inappropriate code in some scenario. I don't know from where you have pulled "blaming the language" because nobody did that.