Hi Baskan,
please keep in mind, that Linux is the "idle task" of rtl. So reads and
writes from the rtl side can not be interrupted by the user side.
So it is not sharing resources with equal partners.
If rtl is the producer of data, you will always have concistancy of the
written data seen from user side.
The problem occurs, when user side writes are being interrupted by rtl.
The simplest way is setting a flag within the mbuff space from the user side
before writing memory from user side and reset it from the user side when
writing has finished. The rtl side can poll within a loop until this bit is
reset from the user side. the rtl side reads only when this bit is reset.
Keep in mind that reading from rtl side can not be interrupted by newly
writes from user side.
You can also set another flag from rtl side to signalize that reading has
been done. This bit should be reset by user side.
In my eyes a better method is reading the mbuff from rtl side only if this is
signalized from user side. This should be done with a fifo. Every time user
side changes data, it sends a message to the fifo. A fifo handler on rtl -
side reads mem afterwards. Again keep in mind that this reading can not be
interrupted by newly writes from user side.
If the handler on rtl side has read the data it sets a flag within the mbuff
to signalize that the data has been read. User side waits with new writes
until this bit is set and resets it after it has seen it. In this way you
prevent overruns. Also with this method the user side has to wait, not the
rtl side. This prevents priority inversion which you will have surely with
the classic mutexes.
Ofcourse this still solves not the problem that might occure, if writes from
user side are interrupted with writes from rtl side.
If you have a setup like this, one side must be the master to synchronize all
the traffic.
For examples one rtl thread is the master. You have two fifos, one for
triggering writing one for triggering reading of the user side.
We use mbuff shared mem in all our applications heavily without problem. Our
setup is as follows.
1. rtl side creates mbuff mem and suspends self.
2. User side attaches and initializes all structures within mbuff mem.
3. User side sends a start command thru fifo that wakens up rtl side again
4. rtl side can write anytimes
5. user side can read anytimes
6. user side writes only to mbuff when it is triggered to do that by
rtl side thru a fifo. User side "fires" back to another fifo that writing
hase been done
Does this help a bit ?
Rgds,
- Andreas Motzkus -
inmess GmbH
Borngasse 9 Voice: +49 6152 9779-11
Fax : +49 6152 9779-20
D - 64572 Buettelborn Email : [EMAIL PROTECTED]
On Wednesday 17 July 2002 18:14, you wrote:
> Thank you very much RD,
>
> I am trying some combinations for a week and now really feel bad
> because even though I read lots of good things on the page of FSM labs
> about "shared memory for rtlinux" and started to work on it, I couldnt
> see any example usage of mbuff except "demo.c" of Tomasz
> which unfortunately explains nothing about handshaking. Anyway, including
> RD's advices below, nothing made "my simple for loops" of user task and
> rtlinux thread to share a piece of memory without crashing.
>
> "Approch 1" you wrote below, seems not logical (to me) since the new
> shared memory which will be going to be used as a flag between threads is
> also a shared memory which needs to be protected(am I right?)
>
> I also tried "Approch 2" (used fifos). But failed again probably because
> of that: When forexample user task enters shared area and exits several
> times before rtlinux task,and so it (user task) writes several times to
> FIFO before rtlinux task reads fifo. So rtlinux task will not read
> NULL till it reads all the messages. So , even when the user task is using
> memory, rtlinux task thinks that memory is available...
>
> any advice?
>
-- [rtl] ---
To unsubscribe:
echo "unsubscribe rtl" | mail [EMAIL PROTECTED] OR
echo "unsubscribe rtl <Your_email>" | mail [EMAIL PROTECTED]
--
For more information on Real-Time Linux see:
http://www.rtlinux.org/
