Getting delay of two events

Getting delay of two events

[mark]

Hello,

I have an external library with a task and a function getSync which
returns boolean value (true if it is in sync position, false
otherwise). Now I would like to create another task which will get the
time between two sync (i.e. moments of time when the get_sync function
returns true). Any ideas how can I make it??

Regards, marc

Re: Getting delay of two events

[JPWoodruff]

mark wrote:
> Hello,
>
> I have an external library with a task and a function getSync which
> returns boolean value (true if it is in sync position, false
> otherwise). Now I would like to create another task which will get the
> time between two sync (i.e. moments of time when the get_sync function
> returns true). Any ideas how can I make it??


I've been waiting to see somebody smarter than me say something
constructive, but since it's been quiet, I'll venture a guess

I'm thinking you can't use the interface you told us about to get the
result you seem to need.  Of course there are always compromises, but
here's my reasoning:

If you call getSync and get a false, you have no idea how long to wait
until a hypothetical subsequent call would yield true.   So at best
you'll measure with a precision bounded by the polling rate of your
caller.  Worse yet, if calls to getSync can go from true to false
without external action that you control, you might miss an interval of
"true" altogether.

On the other hand, if you could extend the library's interface so it
could call *your task*, then you might make some progress.  Depending
of course on *its* timing behavior.

John

Re: Getting delay of two events

[Jeffrey Creem]

JPWoodruff@gmail.com wrote:
> mark wrote:
> 
>>Hello,
>>
>>I have an external library with a task and a function getSync which
>>returns boolean value (true if it is in sync position, false
>>otherwise). Now I would like to create another task which will get the
>>time between two sync (i.e. moments of time when the get_sync function
>>returns true). Any ideas how can I make it??
> 
> 
> 
> I've been waiting to see somebody smarter than me say something
> constructive, but since it's been quiet, I'll venture a guess
>

I had the same basic reaction which is why I did not respond. Given the 
defined interface, there is no 'good' way to do this without resorting 
to polling which awlays feels pretty objectionable.

The options I see are

1) Yuck - Create a task that is higher priority than the 'external 
library task' and have it poll at some fixed rate that you know is 
faster than the library task could possibly run (at least 2x faster but 
obviously even faster than that depending on what sort of resolution you 
were looking for on the timer).

2) Less Yucky - Modify the library task to call someone else at the 
start and stop. Tends to introduce artificial coupling and start the 
spider web of coupling that wrecks a nice SW design.

3)Still less -  Add two new entry points to the library task that it 
accepts (with essentially a zero timeout) at the start and stop then 
rendevous with them from the new task - Again you will need to be sure 
that the new task is higher priority so that it can 'make it' to the 
second rendevous point before the library task hits the second accept. 
Downside of this approach is that it will only really work well for one 
external observer.

I think part of the problem here is that we don't really undestand 
enough about the problem space to make a good recommendation.

Re: Getting delay of two events

[Stephen Leake]

Jeffrey Creem <jeff@thecreems.com> writes:

>> mark wrote:
>>
>>>Hello,
>>>
>>>I have an external library with a task and a function getSync which
>>>returns boolean value (true if it is in sync position, false
>>>otherwise). Now I would like to create another task which will get the
>>>time between two sync (i.e. moments of time when the get_sync function
>>>returns true). Any ideas how can I make it??
>
> The options I see are
>
> 1) Yuck - Create a task that is higher priority than the 'external
> library task' and have it poll at some fixed rate that you know is
> faster than the library task could possibly run (at least 2x faster
> but obviously even faster than that depending on what sort of
> resolution you were looking for on the timer).
>
> 2) Less Yucky - Modify the library task to call someone else at the
> start and stop. Tends to introduce artificial coupling and start the
> spider web of coupling that wrecks a nice SW design.
>
> 3)Still less -  Add two new entry points to the library task that it
> accepts (with essentially a zero timeout) at the start and stop then
> rendevous with them from the new task - Again you will need to be sure
> that the new task is higher priority so that it can 'make it' to the
> second rendevous point before the library task hits the second accept.
> Downside of this approach is that it will only really work well for
> one external observer.

4) modify the library task to do the timing. 

Since the library task knows when the events occur, it needs to do the
timing!

-- 
-- Stephe