Re: Reader/writer semaphores

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Bhanu,

I think your question is -
If user thread UT1 is trying to read some data (through sys call because you cannot access kernel data directly), which is modifiable by kernel thread KT1 then along with the protection of your critical section(where you are reading the data) the data, which KT1 might update should also be protected? I mean should not be updated unless you up the semaphore?

Is this what you are asking????

If yes -
The answer is yes. The data, which you read (through sys call) might get updated even before you up the semaphore, because its your semaophore and kernel doesnt try to acquire user created semaphore before updating its data. Kernel doesnt know who is accessing what through sys call.

Otherwise -
If you are in user land then just think about the user threads, which might update the data. Usually before entering into the critical section the reader tries to get read semaphore and the writer tries to get the write semaphore. Once a reader thread gets a read semaphore, no writer can get the write semaphore (and thus cannot update data) unless reader signals the semaphore.
Thus acquiring a read sem protects your data (which is updated in critical section).

Does that answer your question?

Let me know if you have more confusion on this.

Thanks
-A

On Wed, Apr 2, 2008 at 11:52 PM, bhanu nani <bhanu.lnxnew@xxxxxxxxx> wrote:
Hi Fabio,

My understanding: Semaphore are the tools to protect a region of code
by bloking access to other threads access while the first thead is
accessing it. Let it be any semaphore this is what it does.

 global x;
 up
    /* critical section - any thing*/
    *fpos+=count;
    mystruct->size = *fpos;
    mystruct->xxx = *fpos+ count;
 down

What u say is:
What you are missing is that, in reading, there is NO manipulation of
the data you read. These are what are protected.

But, there is something like which from location u read and till which
location which are part of kernel file attributes. Is there no need to
protect them? or some location updates to my own structure which I
have to make for future use.

- Bhanu

On 4/1/08, Fabio De Francesco <fabiomdf@xxxxxxxx> wrote:
> On Tuesday 01 April 2008 23:57:47 bhanu nani wrote:
> >Hi guys,
> >
> >I was studying on reader-writer semaphores in LLD3. Refered to some
> >samaphore books. but some clarity is missing.
> >
> >Reader/Writer Semaphores:
> >The critical section between down_read, up_read semaphores provides
> >read-only access to the protected resources.
> >
> >I assume that any data in between thi calls is considered protected resources.
> >As there is no data manipulation what it means is reader1/ reader2 can
> >execute the same instrction simultaniously. but how is that possible.
> >How can a perform a read a read aeithout data manipulation i.e.
> >updating user buffers, updatinf the fpos, count. Will these not need
> >protection between the readers themselves i.e. reader1, reader2,
> >...readerN
> >
> >How does this happen?
> >
> >Regards,
> >
> >Bhanu
>
> Dear Bhanu,
>
> What you are missing is that, in reading, there is NO manipulation of the data you read. These are what are protected. Buffers, fpos, counters and anything needed to comply are not part of the kernel structure the semaphore is protecting.
>
> You talked about "USER buffers...". May be you meant "PROCESS" ones. You forget that any process, in kernel mode, has his working memory: read 'Kernel Stack'.
>
> Regards,
>
> fabio de francesco
>
>
> --
> To unsubscribe from this list: send an email with
> "unsubscribe kernelnewbies" to ecartis@xxxxxxxxxxxx
> Please read the FAQ at http://kernelnewbies.org/FAQ
>
>

--
To unsubscribe from this list: send an email with
"unsubscribe kernelnewbies" to ecartis@xxxxxxxxxxxx
Please read the FAQ at http://kernelnewbies.org/FAQ



[Index of Archives]     [Newbies FAQ]     [Linux Kernel Mentors]     [Linux Kernel Development]     [IETF Annouce]     [Git]     [Networking]     [Security]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux RAID]     [Linux SCSI]     [Linux ACPI]
  Powered by Linux