On Thu, 4 Oct 2007, Morten Mossige wrote:
Hi
I'm porting an application from another realtime-os to Linux. This
application makes use of intLock() from time to time. I still need the the
application to be compilable on both Linux and my old os, so I need a
portabel intLock()
I have tried the following approach:
When a thread needs to do intLock, I boost the thread-pri to max, and when
the thread does intUnLock() I set the thread-pri back. This woorks quite ok,
but only on UP machines. On SMP machines you get into trouble.
but by using this approach, I will also lock other threads in other
applications running on Linux.
That is a side effect of intLock(), too.
But intLock/intUnlock are relatively cheap operations.
pthread_setschedprio() is expensive because it involves a system call.
What I really need is a way of blocking all other threads in my application,
without affecting other applications.
Are you sure you need to prevent all other threads from preempting the
current one? Isn't it just a cheap way of implementing a mutex?
I know I can use mutex'es and semaphores, but that will require a major
rewriting of the application, and that is somthing I dont want to do.
Can someone come up with an idea how this is done best?
The code paths sharing the data you need to protect via intLock should
also have intLock/intUnlock around them or being interrupthandlers in the
original application. What about having a global "interrupt_mutex" and
make two functions
int intLock()
{
pthread_mutex_lock(&interrupt_mutex);
return 0;
}
void intUnlock(int level)
{
pthread_mutex_unlock(&interrupt_mutex);
return 0;
}
and put in extra intLock/intUnlock around the original interrupthandlers.
Esben
Morten
-
To unsubscribe from this list: send the line "unsubscribe linux-rt-users" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
-
To unsubscribe from this list: send the line "unsubscribe linux-rt-users" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
