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=-0.3 required=5.0 tests=BAYES_00,
	REPLYTO_WITHOUT_TO_CC autolearn=no 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!.POSTED!not-for-mail
From: Georg Bauhaus <bauhaus@futureapps.invalid>
Newsgroups: comp.lang.ada
Subject: Re: high frequency time stamping (Was: Simple Components 4.12 with
 MQTT implementation released)
Date: Wed, 20 Apr 2016 09:55:33 +0200
Organization: A noiseless patient Spider
Message-ID: <nf7cfa$mv8$1@dont-email.me>
References: <nejfta$lmg$1@gioia.aioe.org>
 <d536dcf9-e710-4ff7-9953-4272dda304f6@googlegroups.com>
 <nenq6h$18jn$1@gioia.aioe.org>
 <6d3b7ac5-8fc6-406c-8aac-947d25a78249@googlegroups.com>
 <neohin$ttp$1@gioia.aioe.org> <nep0d9$vnc$1@dont-email.me>
 <c0a6c1c9-ac45-4e16-84f8-129134287764@googlegroups.com>
 <neq74m$1lbc$1@gioia.aioe.org>
 <a92ea534-9221-40b0-8219-08abcff6ccda@googlegroups.com>
 <ner00g$1207$1@gioia.aioe.org>
 <bcfa1ebb-79ef-4002-9679-c5eebdb16291@googlegroups.com>
 <ner4vs$1b0f$1@gioia.aioe.org>
 <7e104831-cec6-4b04-8671-17e8bdcdae9c@googlegroups.com>
 <nf596p$epv$1@gioia.aioe.org> <nf59tc$ui7$1@dont-email.me>
 <nf5c7e$k4m$1@gioia.aioe.org>
Reply-To: nonlegitur@futureapps.de
Mime-Version: 1.0
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit
Injection-Date: Wed, 20 Apr 2016 07:52:10 -0000 (UTC)
Injection-Info: mx02.eternal-september.org;
 posting-host="162894e8d5b8facedb834832b32fde36";
	logging-data="23528"; mail-complaints-to="abuse@eternal-september.org";
	posting-account="U2FsdGVkX18P/5fLOoaV7wPoa3CH0TUsjIEpw65bGVo="
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:38.0)
 Gecko/20100101 Thunderbird/38.7.2
In-Reply-To: <nf5c7e$k4m$1@gioia.aioe.org>
Cancel-Lock: sha1:UdKYUqeUdi173tOpONz6qqQQero=
Xref: news.eternal-september.org comp.lang.ada:30204
Date: 2016-04-20T09:55:33+02:00
List-Id: <comp.lang.ada>

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.
  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.
  (For a case at hand, the measuring devices will be collecting only
about 10-200 signals/second, yet mustn't have their batteries emptied.)