Need help to clear my doubts about RTOS

Status
Not open for further replies.

sukhdeepmankoo

Member level 2
Joined
May 14, 2009
Messages
47
Helped
1
Reputation
2
Reaction score
0
Trophy points
1,286
Activity points
1,616
RTOS

hi ,
have u ever worked on RTOS?
I have doubts. kindly help to get rid of dilemma.

1) what is the difference between signal and event?
2) what is the difference between mutex and binary semaphore?

i have searched on net, but failed to clear doubts.
Can u help me?

Thanks.
Sukhdeep Singh.
 

Re: RTOS

Regarding mutex vs binary smaphore.
A mutex is like a binary semaphore with the following differences:
1. A mutex has an owner
2. A mutex solves priority inversion using priority inheritance or priority cieling protocol
3. A mutex can be locked recursively
4. A mutex is used in mutual exclusion while a binary semaphore can be used for signaling events as well

Regarding signals and events.
Signals can be seen as a mean of software interrupts. Whenever a signal occurs, a handler runs. It is a mean of IPC.
Events are similar to the signals but with exception that u have to wait for the event urself. The simplest way is to implement it using a binary semaphore.

I made a free course about RTOS. The course is found at https://embedded-tips.blogspot.com/search/label/RTOS

It will be useful speciall for mutexes and sempahores.
--
Amr Ali
 

Thanks,
Regarding mutex vs binary smaphore.
A mutex is like a binary semaphore with the following differences:
1. A mutex has an owner
4. A mutex is used in mutual exclusion while a binary semaphore can be used for signaling events as well

is semaphore do not have owner. but suppose if we have declared muxtex for variable access in two tasks(i.e task1 and task2). now task1 gain access to muxtes variable. no other task can released the mutex variable till control does not get out of common variable. but this can be performed by binary semaphore.

then how can say that mutex has owner while binary semaphore can not.
second thing, binary semaphore is too used for mutual exclusion and what abt signaling events.

2. A mutex solves priority inversion using priority inheritance or priority cieling protocol
3. A mutex can be locked recursively

how can mutex be locked recursively? while at a time mutex only holed single value like 0 or 1(like binary semaphore).


Signal vs Event.

Signals can be seen as a mean of software interrupts. Whenever a signal occurs, a handler runs. It is a mean of IPC.
Events are similar to the signals but with exception that u have to wait for the event urself. The simplest way is to implement it using a binary semaphore.

is it means that event can be just like polling mechanism.

Thanks, kindly help me abt these doubts.
 


Because in binary semaphore a task can acqquire it and any task can release it. For mutex, the task that acquired the mutex becomes its owner and its the only task that can release it.

then how can say that mutex has owner while binary semaphore can not.
second thing, binary semaphore is too used for mutual exclusion and what abt signaling events.
A binary semaphore can be used in mutual exclusion as well but will suffer from priority inversion. Mutex is preferred to a binary semaphore.

Regarding signaling events: Task A tries to acquire a semaphore and blocks cause semaphore value is zero. Task B then release the sempahore. So the blocked task waited for another one to signal it.


how can mutex be locked recursively? while at a time mutex only holed single value like 0 or 1(like binary semaphore).
Thats implementation dependent and can be done cause the mutex owner is know to the RTOS. So if i am acquiring the mutex and i want to lock it again i wont be blocked.


Events can be seen as using a semaphore in wait/signal situation. I just block till something happens. Using a signal, I do my work till some one signals me, I handle the signal then go on working.

--
Amr
 

Thanks Amr Ali.
I am reading RTOS, if i will have any further doubts, then i will again ask.
Thanks a lot.
Sukhdeep Singh.
 

Status
Not open for further replies.
Cookies are required to use this site. You must accept them to continue using the site. Learn more…