[fpc-devel] Suggestion: reference counted objects

[Sven Barth]

Am 23.09.2014 11:11 schrieb "Giuliano Colla" <giuliano.colla at fastwebnet.it>:
> You have a number of threads creating thousands of data objects, which
should be processed by "consumer" threads. Creating threads are unaware of
how data will be used (it may depend on active options, and it follows the
golden rule of "reusable code") so they can't send those objects anywhere.
Therefore pointers to those objects are inserted in a list.
>
> A "consumer" thread can either process a data object, and then dispose of
it, or leave it in the list for further processing, or move it to a
different list, again depending on the selected options.
> This scheme can apply to quite a number of applications, from data
collected in a real-time process to data-base transactions, etc.
>
> However you attempt to apply reference counting in this scheme, you'll
realize that either it doesn't work at all, or it forces you to add a
considerable amount of code, whose purpose would be only to fool reference
counting, and artificially increase or decrease reference count.

I don't see where you would need to play around with the reference count in
your example. Following assumptions: the list only takes reference counted
objects (currently this would be interfaces, with the class-ARC that would
be object instances).
Now the producers add workitems to the list and may or may not keep an own
reference to that workitem (so refcount is - simplified - either 1 or 2).
A consumer now takes one object from the list, processes it, and either
discards it ("obj := Nil;") or reinserts it in the list. If it discards it
then either the object is now freed, if the producer did not keep a
reference or it's not if it did. If the consumer puts it back in the list,
then the refcount it still either 1 or 2 depending on what the producer did.

So I don't see where you'd need to manually fiddle around with the
reference count here.

If you'd of course mix reference and non-reference counted workitems then
you'd need to handle this, but then you should maybe overthink your
implementation...

Regards,
Sven
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freepascal.org/pipermail/fpc-devel/attachments/20140923/4913f857/attachment.html>