Re: Reader/writer semaphores

["sahlot arvind" <asahlot@xxxxxxxxx>]

Hi Bhanu,

Thanks for the explanation, I understand your question now. 
As Erik said, I would say you should not try to protect region of code using semaphore.

Anyways, your code - 
----------------
read()

{
    ...
    KTx starts
    down_read()
    /*critical section*/
   a++;
    up_read()
    KTx ends
}
-----------

I dont know whether 'a' is local or global. IF IT IS - 

LOCAL:
you dont need any sync technique to protect it since local variables are stored on stack and each thread has its own stack and thus its own copy of local variables.

GLOBAL:
Yes. In this case you need to protect it, because any thread can access it. BTW if you look closely at 

a++; ==> a = a+1;

You are actually writing 'a' and not just reading. Do you agree? And thus in this case you should use write semaphore and not read. If you use write semaphore, given 'a' as global variable it will be protected surely.

Does that answer your question? Let me know if you need more explanation on this.

Thanks 
- A

On Thu, Apr 3, 2008 at 10:09 PM, bhanu nani <bhanu.lnxnew@xxxxxxxxx> wrote:

Hi  Sahlot,

First thing, I am not speaking about the user semaphore instead it is
a kernel semaphore.I am trying ot protect the "critical section" in
kernel space from different readers. I am trying to understand the
read/write semaphore usage described in the LLD3 book.

Can I use read semaphores to project my read impl of my driver.
How does the read semaphore protect my critical section (update fpos,
count, my local stuff) between multiple readers. Will it?
Will down_read block the second reader from entering critical section
when first reader how not yet exited? this is what I want.
If it does so, How can Im protect updates like a++; between readers.
Please see my impl below.

If
UTx := UT1, UT2
KTx := KT1, KT2
then

UTx
------------------------------------
read()
{
   ...
   KTx starts
   down_read()
   /*critical section*/
  a++;
   up_read()
   KTx ends
}

Regards,
Mukund

On 4/3/08, sahlot arvind <asahlot@xxxxxxxxx> wrote:
> 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
> >
> >
>
>