EPICS Home

Experimental Physics and Industrial Control System


 
1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  <20062007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024  Index 1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  <20062007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024 
<== Date ==> <== Thread ==>

Subject: RE: About: timeout handler of epicsTimer
From: "Mark Rivers" <[email protected]>
To: "Andrew Johnson" <[email protected]>, "Jun-ichi Odagiri" <[email protected]>
Cc: "EPICS tech-talk" <[email protected]>
Date: Thu, 12 Jan 2006 19:09:29 -0600
Andrew wrote:

> Yes it is allowed, but you should be aware of the 
> implications of this: 
> If the semaphore blocks, then none of the other epicsTimers 
> that use the  same epicsTimerQueue will be executed until the
semaphore is released 
> and the callback/notify routine returns.  It is not advisable for a 
> timer on the system shared timer queue to block for any signficant 
> period of time in its callback/notify routine.  The use of 
> printf() and similar functions is fine though because it should not
block for any 
> significant period of time.

I don't think I agree with the statement that printf() should not block
for any significant period of time.

On vxWorks printf() does block, and since the I/O is often going to a
9600 baud console port, it can be very slow.  In fact if the user types
^S to pause the output the task will hang until ^Q is typed.

Here's a little test program that measures how many clock ticks are
required to use printf() to print 100 output lines:

corvette> more printf_test.c 
#include <tickLib.h>
#include <stdio.h>

void printf_test()
{
    int i;
    long int start;

    start = tickGet();
    for (i=0; i<100; i++) printf("This is line %d\n", i);
    printf("Total ticks=%ld\n", tickGet()-start);
}

Here's the output under normal circumstances:

ioc13lab> printf_test                                
This is line 0
This is line 1
This is line 2
This is line 3
...
This is line 96
This is line 97
This is line 98
This is line 99
Total ticks=72
value = 15 = 0xf

So it took 72 clock ticks, or over 1 second.

If I press ^S for a while during the output, the task hangs while that
is going on, and I got 546 clock ticks while I waited about 10 seconds.

So I don't think it's a good idea to call printf in a callback routine.

epicsPrintf() is much better, since it just puts output in a buffer, and
does not wait for the actual I/O to complete.

Mark



Replies:
RE: About: timeout handler of epicsTimer Jun-ichi Odagiri

Navigate by Date:
Prev: RE: About: timeout handler of epicsTimer Jun-ichi Odagiri
Next: Re: vxStats Benjamin Franksen
Index: 1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  <20062007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024 
Navigate by Thread:
Prev: RE: About: timeout handler of epicsTimer Jun-ichi Odagiri
Next: RE: About: timeout handler of epicsTimer Jun-ichi Odagiri
Index: 1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  <20062007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024