On Thu, Oct 17, 2002 at 04:54:07PM +0300, Momchil Velikov wrote:
> >>>>> "Momchil" == Momchil Velikov <velco@fadata.bg> writes:
>
> >>>>> "Nagaraj" == Nagaraj <nagaraj@smartyantra.com> writes:
> Momchil> FWIW, the problem is the classic producer-consumer problem with
> Momchil> solutions described in _any_ OS textbook.
No, it probably isn't. I expect that the camera is giving frames at
constant rate and the video encoder wants to grab the latest if it's
completed, but does not care when it missed some.
> Momchil> Thus, the right solution would be to use semaphores. But, AFAIK,
> Momchil> there are no semaphores shared between the userspace and the kernel.
This is rather oversimplified. That any OS textbook will tell you, that
all the synchronization primitives are equivalent.
The sigwait mechanizm should actually be correct synchronization.
Having POLLIN on the descriptor iff a complete buffer is ready would be
better.
> Momchil> Probably futexes can do the work.
Why when character devices already are perfect message queues?
> Alternatively (and better),
Don't agree with better. It adds more ioctl crap. It would be better if
it was poll instead of ad-hoc ioctl.
But yes, mmap has advantage being no-copy.
I still don't like the ioctls for synchronization, since the pocess has
to also poll for the network to accept the data. And this would force it
to have a helper thread just because it does not integrate with poll.
Note that signals do integrate with poll. If you don't want to loose
signals, you have a handler, that writes a signle byte to an auxiliary
pipe and poll on that. On POLLIN on this pipe, you know signal has
arrived.
Note, that when enough signals stack so they fill the pipe buffer, you
start to loose them (the pipe must be non-blocking - otherwise it's
a deadlock).
But here you don't care. The mpeg encoder want's to eat all pending
signals, since if there are 2 or more stacked, it already missed those
frames and simply wants to skip them.
> Have the driver allocate 2 buffers and mmap() them into the process.
> Have the driver create 2 semaphores (initially zero) and let the app
> post and wait on them with ioctls.
>
> void *buf[2];
>
> buf [0] = mmap (fd, ...);
> buf [1] = buf [0] + HALF_BUFFER_SIZE; /* GCC extension :) */
>
> no = 0;
> while (!done ())
> {
> /* Let the driver know a buffer is available. DMA starts
> if not started already. */
> ioctl (fd, POSTSEM_0);
> /* Wait until DMA interrupts and the interrupt handler signals the
> semaphore. Driver continues filling the other buffer. */
> ioctl (fd, WAITSEM_1);
>
> /* Data is in buffer, no copying needed. */
> do_stuff (buf [no]);
>
> /* Switch buffers. */
> no = !no;
> }
You seem to have the semaphores wrong. There are two semaphores for each
buffer. A read one (meaning "you can read") and a write one (meaning
"you can write"). Both WRITE ones must be initialy UP, the READ ones
initialy DOWN. Then, in each iteration you must DOWN READ no, deal with
the buffer and UP WRITE no. Then switch buffers.
But that is proper solution for producer-consument. This is NOT
producer-consument.
> One can add buffers to compensate for jitter. On a real-time OS two
> buffers ought to be enough. Ok ?
That's drivers choice! Driver allocates them (event here).
-------------------------------------------------------------------------------
Jan 'Bulb' Hudec <bulb@ucw.cz>
--
Kernelnewbies: Help each other learn about the Linux kernel.
Archive: http://mail.nl.linux.org/kernelnewbies/
FAQ: http://kernelnewbies.org/faq/
