Re: [PATCH] driver: ip27-rtc - convert ioctl to unlocked_ioctl

[Cyrill Gorcunov <gorcunov@gmail.com>]

[Jiri Slaby - Mon, Jan 14, 2008 at 04:59:22PM +0100]
> On 01/14/2008 04:38 PM, Cyrill Gorcunov wrote:
>> Jiri, I mean rtc_open() is protected by spinlock+status from being
>> opened simultaneously by a few processes. *But* lets imagine the
>> following situation - this fd (file descriptor) is opened by one
>> multithreaded application so all threads have an access to this
>> fd. Then one thread reads rtc periodically thru unlocked_ioctl
>> and another thread set new time from time to time. So the question
>> I have - is it possible to get second thread stopped at attemption to
>> get rtc spinlock while another thread is setting the new time? Or
>> this situation never-ever could be? i'm not really familiar with
>> process management in Linux and as result could be wrong.
>
> Access to global variable 'rtc' (the rtc itself) is serialized through the 
> spinlock, I see no problem there. If you call read-read-write-read from 4 
> tasks in userspace, it might be _still_ (no change) reordered to e.g. 
> write-read-read-read by the scheduler.
>
> In fact, the reading process is stopped while the another one is writing 
> the time (due to spinlock).
>

Yes, process would be stopped, and not *just* stopped but could spend
all his cpu time-slice in attempt to get spinlock (espec if set time is
much longer than read), but if we use mutex here the process could just
sleep instead of trying to get spinlock granted. Am I wrong? Or this is
not worth to do it?

		- Cyrill -