Re: [Xenomai-core] Synchronization of shared memory with mutexes

[Philippe Gerum <rpm@xenomai.org>]

On 01/10/2012 04:04 PM, Jan-Erik Lange wrote:
>
> Hello,
>
> I have a question about basics of the synchronization of shared memory
> with mutexes.
>
> The situation: The Sender is a RT task (primary domain) and the
> recipient is a non-RT task (usually in the secondary domain). Namely,
> the receiver is used to interact with a Web server. He calls to syscalls
> and stuff and because of that he's usually in the secondary mode.
>
> Suppose the sender has written something to the shared memory: He uses
> mutex for synchronization, so he calls the rt_mutex_release() function.
>
> The receiver will now get time to work from the scheduler. He calls
> rt_mutex_acquire() function to lock the shared memory. Then a context
> switch occurs from the secondary mode in the primary mode. He has now
> the resource for himself.
>
> Now the scheduler lets sender-task to work and it wants to write
> something. So it calls rt_mutex_acquire() function. And now comes my
> question: Provides rt_mutex_acquire() a mechanism to signal the cheduler
> to immediately continue with the recipient-task? If so, how does the
> rt_mutex_acquire() function tells the scheduler that?

There are two tasks controlled by the same (Xenomai) scheduler. One is 
trying to grab a mutex the other one holds, so it is put to sleep on 
that mutex. The scheduler will simply switch to the next ready-to-run 
task since the sender task cannot run anymore, and that next task may be 
the receiver task. There is no special signaling magic required.

>
> I came out because I in the documention I read the term "Rescheduling:
> always".
>

The documentation for rt_mutex_acquire is "Rescheduling: always unless 
the request is immediately satisfied or
timeout specifies a non-blocking operation.".

> Best regards
> Jan
>
>
>
> _______________________________________________
> Xenomai-core mailing list
> Xenomai-core@domain.hid
> https://mail.gna.org/listinfo/xenomai-core


-- 
Philippe.