[fpc-devel] Suggestion: reference counted objects

[Giuliano Colla]

Hi Boian,

I'm easily convinced that you've developed a lot of things using 
reference counting. Design is the art of compromise, and possibly in 
your class of application that's the best compromise.
But we should never forget that our class of applications isn't the only 
possible one in the world. What is a bonus for you might be either 
useless or extremely harmful for someone else.

I might, for example, tell you that my company has been successfully 
implementing since more than 30 years a class of applications for the 
control of industrial processes, with hundreds of threads running 
simultaneously in a multi-CPU environment, with thread synchronization 
in the sub-millisecond range (with time it has improved down to the 
sub-microsecond area, with the evolution both of hardware and software 
tools), where reference counting simply doesn't apply, because of the 
specific nature of the problems. All the required resources must be 
created at startup, and they can only be destroyed when the process is 
stopped, at the end of the day in some cases, at the end of the week or 
for the annual vacations in others.

Or that we have another class of multithreaded applications (not so many 
as the other ones, and with just around 14 years of history) where 
objects are mainly manipulated by means of lists of pointers, and where, 
again, reference counting doesn't apply, because an object can't 
possibly be aware of what happens to one or several pointers pointing to it.
In some cases it's required that destroying the list the objects are 
destroyed also, in other cases they must be kept. But this must be 
decided by program logic, not by a generic algorithm.

In any case, in our range of applications, memory leakage due to objects 
not destroyed, or crashes due to unduly destroyed objects has never been 
an issue.

For those reasons I have nothing against reference counted objects, 
provided I'm not forced to use them, because, in our class of 
applications we would only suffer the disadvantages.

Should TObject become reference counted by default, I'm afraid that for 
most of us, me included, switching to ANSI C would become a choice to be 
seriously considered, like Peter Popov suggested in this thread...

Kind regards,

Giuliano

Il 20/09/2014 21:27, Boian Mitov ha scritto:
>   Hi Giuliano,
> All of our libraries, are heavily multithreaded, and use exclusively 
> reference counting with interfaces, as well as lazy evaluation nested 
> object reference counting for performance.
> We have been doing this for over 11 years with great success, and we 
> continue to expand the functionality.
> Not only is it doable, but it is nearly impossible to do really 
> complex heavily distributed threading without it. Trust me, I have 
> been doing multithreading since the days we had to implement it in 
> interrupt cascades in 6502/6800 8 bit processors 30 years ago ;-) . I 
> know what it takes to do it in assembler, C, C++, Delphi, with and 
> without OOP, as well as with and without ref. canting ;-) . I have 
> done them all...
> With best regards,
> Boian Mitov
>
> -------------------------------------------------------
> Mitov Software
> www.mitov.com
> -------------------------------------------------------
> *From:* Giuliano Colla <mailto:giuliano.colla at fastwebnet.it>
> *Sent:* Saturday, September 20, 2014 11:33 AM
> *To:* FPC developers' list <mailto:fpc-devel at lists.freepascal.org>
> *Subject:* Re: [fpc-devel] Suggestion: reference counted objects
> Il 20/09/2014 19:20, Boian Mitov ha scritto:
>>   Hi Chriss,
>> Personally I favor reference counted objects. While there are 
>> interfaces as you pointed, and in Delphi you can even use smart 
>> pointers now, there is still a lot of cases when you need to use 
>> objects, and have to manually free them.
>> In single threaded environment that is not such an issue, but in 
>> parallel and heavily multithreaded environments, reference counting 
>> is a life saver.
>
> Can you explain how reference counting can be safely implemented in a 
> parallel multithreaded environment, without heavily affecting performance?
> A mere increment or decrement of count means to get a lock and to 
> release a lock on that object. Application code can know what is 
> thread safe and what is not, and use lock only when appropriate.
> A general mechanism to be reliable should take into account all 
> possibilities. If it does, it will block threads even when 
> unnecessary. If it doesn't, it will be unsafe.
>
> What do I miss?
>
> Giuliano
>
> ------------------------------------------------------------------------
> _______________________________________________
> fpc-devel maillist  -  fpc-devel at lists.freepascal.org
> http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
>
>
> _______________________________________________
> fpc-devel maillist  -  fpc-devel at lists.freepascal.org
> http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freepascal.org/pipermail/fpc-devel/attachments/20140921/5d7a5c03/attachment.html>