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.co...@fastwebnet.it>
*Sent:* Saturday, September 20, 2014 11:33 AM
*To:* FPC developers' list <mailto:fpc-devel@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@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
_______________________________________________
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
_______________________________________________
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
