Argonne National Laboratory

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  Index 1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  <20062007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017 
<== Date ==> <== Thread ==>

Subject: RE: About: timeout handler of epicsTimer
From: "Mark Rivers" <rivers@cars.uchicago.edu>
To: "Andrew Johnson" <anj@aps.anl.gov>, "Jun-ichi Odagiri" <jun-ichi.odagiri@kek.jp>
Cc: "EPICS tech-talk" <tech-talk@aps.anl.gov>
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 
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 
ANJ, 02 Sep 2010 Valid HTML 4.01! · Home · News · About · Base · Modules · Extensions · Distributions · Download ·
· EPICS V4 · IRMIS · Talk · Bugs · Documents · Links · Licensing ·