[Xenomai] behavior of cobalt-wrapped fwrite()

[Xenomai] behavior of cobalt-wrapped fwrite()

[George Broz]

Hello,

I'm running Xenomai 3.0.2, with Linux 3.18.20. I have an application
that uses the Cobalt (POSIX) API, using several Xenomai
threads/tasks (all priority > 0).

One of these threads makes several calls to fwrite(), each time
appending a chunk of data to a given open file on the flash file
system. The fwrite()'s are spread out; in between the calls, other
threads get a chance to run. Eventually, the file is fclose()'d.

The resulting file should be around 2MB, but ends up being about
200kB (and I'm not sure which 200kB that is). If I sum up the
returns of each fwrite() call made, then that returns the expected
 2 MB size (which the resulting file does not reflect).

Compiled as a Linux application, this use of fwrite() works.

Running on Xenomai, if I use:

    __real_fwrite() instead of fwrite()

then that also works (i.e. the full 2MB gets written).

I have tried to "fflush" after each fwrite(), and before the fclose(),
but that made no difference.

A similar situation is described for Xenomai 2.6.3 in this thread:
http://xenomai.org/pipermail/xenomai/2015-January/032975.html

My question is... is this an issue with Cobalt's fwrite()
implementation, or am I expected to use __real_fwrite() in such
cases? And then, should I be using __real counterparts
for fopen, fread, etc. as well? And what is the litmus test
for using the __real_XXX prefixed function calls?

Thanks in advance for any advice!

--George Broz
Moog Industrial Group

Re: [Xenomai] behavior of cobalt-wrapped fwrite()

[Philippe Gerum]

On 12/27/2016 06:54 PM, George Broz wrote:
> Hello,
> 
> I'm running Xenomai 3.0.2, with Linux 3.18.20. I have an application
> that uses the Cobalt (POSIX) API, using several Xenomai
> threads/tasks (all priority > 0).
> 
> One of these threads makes several calls to fwrite(), each time
> appending a chunk of data to a given open file on the flash file
> system. The fwrite()'s are spread out; in between the calls, other
> threads get a chance to run. Eventually, the file is fclose()'d.
> 
> The resulting file should be around 2MB, but ends up being about
> 200kB (and I'm not sure which 200kB that is). If I sum up the
> returns of each fwrite() call made, then that returns the expected
>  2 MB size (which the resulting file does not reflect).
> 
> Compiled as a Linux application, this use of fwrite() works.
> 
> Running on Xenomai, if I use:
> 
>     __real_fwrite() instead of fwrite()
> 
> then that also works (i.e. the full 2MB gets written).
> 
> I have tried to "fflush" after each fwrite(), and before the fclose(),
> but that made no difference.
> 
> A similar situation is described for Xenomai 2.6.3 in this thread:
> http://xenomai.org/pipermail/xenomai/2015-January/032975.html
> 
> My question is... is this an issue with Cobalt's fwrite()
> implementation,

Does passing --print-buffer-size=2097152 as a command line argument
change/improve the behavior?

 or am I expected to use __real_fwrite() in such
> cases? And then, should I be using __real counterparts
> for fopen, fread, etc. as well? And what is the litmus test
> for using the __real_XXX prefixed function calls?

When a fairly high output rate or volume is expected, __real_* should be
preferred when the caller is a non-RT Xenomai thread (i.e. SCHED_OTHER
or SCHED_WEAK), or whenever such thread is not a Xenomai thread (i.e.
not created by libcobalt's pthread_create() but glibc's).

-- 
Philippe.

Re: [Xenomai] behavior of cobalt-wrapped fwrite()

[George Broz]

On 27 December 2016 at 11:37, Philippe Gerum <rpm@xenomai.org> wrote:
>
> On 12/27/2016 06:54 PM, George Broz wrote:
> > Hello,
> >
> > I'm running Xenomai 3.0.2, with Linux 3.18.20. I have an application
> > that uses the Cobalt (POSIX) API, using several Xenomai
> > threads/tasks (all priority > 0).
> >
> > One of these threads makes several calls to fwrite(), each time
> > appending a chunk of data to a given open file on the flash file
> > system. The fwrite()'s are spread out; in between the calls, other
> > threads get a chance to run. Eventually, the file is fclose()'d.
> >
> > The resulting file should be around 2MB, but ends up being about
> > 200kB (and I'm not sure which 200kB that is). If I sum up the
> > returns of each fwrite() call made, then that returns the expected
> >  2 MB size (which the resulting file does not reflect).
> >
> > Compiled as a Linux application, this use of fwrite() works.
> >
> > Running on Xenomai, if I use:
> >
> >     __real_fwrite() instead of fwrite()
> >
> > then that also works (i.e. the full 2MB gets written).
> >
> > I have tried to "fflush" after each fwrite(), and before the fclose(),
> > but that made no difference.
> >
> > A similar situation is described for Xenomai 2.6.3 in this thread:
> > http://xenomai.org/pipermail/xenomai/2015-January/032975.html
> >
> > My question is... is this an issue with Cobalt's fwrite()
> > implementation,
>
> Does passing --print-buffer-size=2097152 as a command line argument
> change/improve the behavior?

That improves the behavior. Sometimes it succeeds and then fails
on the next file written which is ~1MB. But if I increase it to
--print-buffer-size=4097152 both succeed.

I just read/re-discovered the "application setup and init" page which
describes this argument and its friends. Thanks.

>
>
>  or am I expected to use __real_fwrite() in such
> > cases? And then, should I be using __real counterparts
> > for fopen, fread, etc. as well? And what is the litmus test
> > for using the __real_XXX prefixed function calls?
>
> When a fairly high output rate or volume is expected, __real_* should be
> preferred when the caller is a non-RT Xenomai thread (i.e. SCHED_OTHER
> or SCHED_WEAK), or whenever such thread is not a Xenomai thread (i.e.
> not created by libcobalt's pthread_create() but glibc's).

Good to know. Thanks. In this case the threads all use SCHED_FIFO
and all are created via libcobalt's pthread_create() calls.

So the trade-off here is either provide enough buffer space so that the call
can be handled successfully with the benefit of not dropping (the caller)
out of primary mode, or use the __real_XXX calls which bypass the
buffers but will incur a secondary transition.

We have plenty of memory to spare...

Thanks,
-George

>
> --
> Philippe.