From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=unavailable autolearn_force=no version=3.4.4 Path: eternal-september.org!reader01.eternal-september.org!reader02.eternal-september.org!news.eternal-september.org!mx02.eternal-september.org!feeder.eternal-september.org!aioe.org!.POSTED!not-for-mail From: "Dmitry A. Kazakov" Newsgroups: comp.lang.ada Subject: Re: high frequency time stamping (Was: Simple Components 4.12 with MQTT implementation released) Date: Wed, 20 Apr 2016 10:48:05 +0200 Organization: Aioe.org NNTP Server Message-ID: References: <6d3b7ac5-8fc6-406c-8aac-947d25a78249@googlegroups.com> <7e104831-cec6-4b04-8671-17e8bdcdae9c@googlegroups.com> NNTP-Posting-Host: bqgfK7NL3xTHnr0WRaLl4g.user.gioia.aioe.org Mime-Version: 1.0 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Complaints-To: abuse@aioe.org User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.7.2 X-Notice: Filtered by postfilter v. 0.8.2 Xref: news.eternal-september.org comp.lang.ada:30206 Date: 2016-04-20T10:48:05+02:00 List-Id: On 20/04/2016 09:55, Georg Bauhaus wrote: > On 19.04.16 15:35, Dmitry A. Kazakov wrote: >> On 19/04/2016 14:59, G.B. wrote: >>> On 19.04.16 14:43, Dmitry A. Kazakov wrote: >>>> It is a value and a time stamp, because data are oversampled. There is >>>> no way a conventional OS could respond to each change at this rate. >>> >>> Is it possible to have a volatile variable T representing >>> some point in time and a CAS discipline so that >>> >>> 1. there is one task that updates T at regular intervals and >>> >>> 2. another task that reads T for stamping items more frequently >>> than the first would write updates? >> >> It is an interesting question. Do you mean CAS = content-addressable >> storage? > > Coincidence! While I'd expect the time storing variable to be located > in some kind of privileged location, I had meant CAS to refer to some > thread-safe update mechanism. I now notice that maybe mutex via volatile > storage might already be in place. The method I am using is of a lock-free blackboard. There is single producer that writes onto it without locking. Consumers scan the blackboard without locking starting from the last read position = sequence number. They detect losses through the sequence number going out of the bounds. > All of this would be based on the assumption that reading the time via > system is much more costly than just reading a volatile variable, > while perhaps adding a sequence number for ordering the stamped items > within one time frame. Also separates problems and solutions, as you > indicated. Nothing new, I guess. When a bunch of oversampled values are read, their time stamps are reconstructed, if the hardware is unable to stamp the values. Then the values and stamps are written into the blackboard. So the consumers never need not to care of the way the data came there in first place. > (For a case at hand, the measuring devices will be collecting only > about 10-200 signals/second, yet mustn't have their batteries emptied.) Another user case is when the mobile network traffic must paid for. The producer usually filters out updates which are within the tolerance band in order to reduce the traffic. Everything is running in the push mode, of course. -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de