"Esben Nielsen" <nielsen.esben@xxxxxxxxxxxxxx> skrev i melding news:Pine.LNX.4.64.0710100914180.8140@xxxxxxxxxxxxxx > 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 >> 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 - 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
