[fpc-devel] Suggestion: reference counted objects

[Boian Mitov]

  Hi Sven,

There is no one list.
We have N number o data sources of many different types. The data from each source is processed in a pipeline of threads that cane be reconfigured at any time.
New sources and new data types can be added during the runtime by the customers.
The data from different pipelines can be merged split, sent over network and anything in between.
This is 100% universal high performance high troghput graph parallel processing of very much any type of data solution. You can learn more by looking at the OpenWire Studio as example, (free download), but all the solutions are working this way.
Any other approach has limitations, and indeed more overhead (i.e. additional lists and code just to maintain the data)

With best regards,
Boian Mitov

-------------------------------------------------------
Mitov Software
www.mitov.com
-------------------------------------------------------

From: Sven Barth 
Sent: Tuesday, September 23, 2014 6:06 AM
To: FPC developers' list 
Subject: Re: [fpc-devel] Suggestion: reference counted objects

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



--------------------------------------------------------------------------------
_______________________________________________
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/20140923/c044db40/attachment.html>