Messages in this thread |  | | Subject | Re: [GIT PULL] Please pull proc and exec work for 5.7-rc1 | From | Bernd Edlinger <> | Date | Sat, 4 Apr 2020 06:23:41 +0200 |
| |
On 4/4/20 1:16 AM, Waiman Long wrote: > On 4/3/20 4:59 PM, Linus Torvalds wrote: >> On Fri, Apr 3, 2020 at 1:41 PM Waiman Long <longman@redhat.com> wrote: >>> Another alternative is to add new functions like down_read_unfair() that >>> perform unfair read locking for its callers. That will require less code >>> change, but the calling functions have to make the right choice. >> I'd prefer the static choice model - and I'd hide this in some >> "task_cred_read_lock()" function anyway rather than have the users do >> "mutex_lock_killable(&task->signal->cred_guard_mutex)" like they do >> now. >> >> How nasty would it be to add the "upgrade" op? I took a quick look, >> but that just made me go "Waiman would know" ;) >> >> Linus >> > With static choice, you mean defined at init time. Right? In that case, > you don't really need a special encapsulation function. > > With upgrade, if there is only one reader, it is pretty straight > forward. With more than one readers, it gets more complicated as we have > to wait for other readers to unlock. We can spin for a certain period of > time. After that, that reader can use the handoff mechanism by queuing > itself in front the wait queue before releasing the read lock and go to > sleep. That will make sure that it will get the lock once all the other > readers exits. For an unfair rwsem, the writer cannot assert the handoff > bit and so it shouldn't interfere with this upgrade process. > > If there are multiple upgrade readers, only one can win the race. The > others have to release the read lock and queue themselves as writers. > Will that be acceptable? >
Someone pointer out prevoiosly I think that with the real time linux the rwmutex are just mutex and we better not base our desing on that.
To me linux_rt is a must.
Thanks Bernd.
> Cheers, > Longman > > > > Cheers, > Longman >
|  |