Porting intLock()

Discussion:

Porting intLock()

Morten Mossige

2007-10-04 18:58:56 UTC

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 by using this approach, I will also lock other threads in other
applications running on Linux.
What I really need is a way of blocking all other threads in my application,
without affecting other applications.
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?
Morten

Steven Rostedt

2007-10-04 22:16:17 UTC

Permalink

Post by Morten Mossige
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()
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 by using this approach, I will also lock other threads in other
applications running on Linux.
What I really need is a way of blocking all other threads in my application,
without affecting other applications.
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?
Morten

Upping the prio is basically what intLock does really. That is upping it
over the priority of interrupts, which would also mean that you would not
be preempted. So by increasing the prio to max, you have in essence locked
out all interrupts from that CPU, as well as other tasks. So just doing
for you application doesn't make sense. Note, the timer interrupt will
still go off.

Without knowing more about you application, we really cant give much more
advice.

Jaswinder Singh

2007-10-07 13:27:44 UTC

Permalink

Hello Morten,

I think your approach is good if it is working.

Post by Morten Mossige
but by using this approach, I will also lock other threads in other
applications running on Linux.

Someone has to pay. If you are boosting someone on the same time you
are also suppressing others, this is how real-time works.

Post by Morten Mossige
What I really need is a way of blocking all other threads in my application,
without affecting other applications.

If you block other applications they will be affected. No solution for this.

Jaswinder Singh.

Post by Morten Mossige
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?
Morten
-
To unsubscribe from this list: send the line "unsubscribe linux-rt-users" in
More majordomo info at http://vger.kernel.org/majordomo-info.html

Esben Nielsen

2007-10-10 07:34:47 UTC

Permalink

but only on UP machines. On SMP machines you get into trouble.

Post by Morten Mossige
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.

Post by Morten Mossige
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?

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

Post by Morten Mossige
Morten
-
To unsubscribe from this list: send the line "unsubscribe linux-rt-users" in
More majordomo info at http://vger.kernel.org/majordomo-info.html

Morten Mossige

2007-10-10 14:00:41 UTC

Permalink

Post by Esben Nielsen

but only on UP machines. On SMP machines you get into trouble.

Post by Morten Mossige
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.

Post by Morten Mossige
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?

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

Post by Morten Mossige
Morten
-
To unsubscribe from this list: send the line "unsubscribe linux-rt-users" in
More majordomo info at http://vger.kernel.org/majordomo-info.html

Tnx for many good recommendations about porting intLock/unLock.
Currently I'm using priboost, and that works for my application, but I will
look into implementing the lock with a mutex later.

Morten