Hi Sahlot,
I am running an x86 system.
I have gone through the code in rwsem-spinlock.c for __down_read().
There I observed the following things
* The RW_SEM semaphore structure is portecting from between readers
and the task state is being updated and saved into the wait_list.
* But, finally, it is allowing all the readers to pass through the
read_down() unless there is some writer waiting there.
* If there is no writer waiting, every reader is given accesss to
the critical section part.
Means, if I have code like
read_down()
a++;
read_up()
'a' value will have the issue of cuncurency.
In that case, kernel expects no updates to the global structures and
data when locked between read_down/ read_up. Is there any driver in
the entire linux kernel that uses a rw_sem for read/write file
operations implementation.
Please correct me if I am wrong.
Also, find the code snippet from :/linux/drivers/char/mem.c
------------------------------------------------------------------------------------------
down_read(&mm->mmap_sem);
....
....
up_read(&mm->mmap_sem);
/* The shared case is hard. Let's do the conventional zeroing. */
662 do {
663 unsigned long unwritten = clear_user(buf, PAGE_SIZE);
664 if (unwritten)
665 return size + unwritten - PAGE_SIZE;
666 cond_resched();
667 buf += PAGE_SIZE;
668 size -= PAGE_SIZE;
669 } while (size);
670
------------------------------------------------------------------------------------------
Please let me know how is this code trying to handle concurency
situation with cond_resched(); How is that going to help?
This would be a great piece of information.
Regards,
Mukund Jampala
On 4/4/08, bhanu nani <bhanu.lnxnew@xxxxxxxxx> wrote:
> Hi Sahlot,
>
> I fully comply with Erik. I made a wrong statement.
>
> Thanks for your detailed explantion.
> I am trying to use these in implementation of char driver fops in read
> and write.
> Even though it is a read, there will some obvious updates to either
> global driver stuctures, *fpos(which is the address used by kernel to
> get fposition updates).
>
> My simple question is:
> Will there be no critical section areas between(across) multiple readers.
>
> IF yes,
> If we use RWSEM, how will it help in protecting those critical
> section. is it designed for it? This situation is very much possible.
> Any call to kernel functions passing a pointer will arise this situation. right?
>
> IF no,
> No worries. But, I understand this is not possible.
>
> A statement in ch5, LDD3:
> A call to down_read provides read-only access to the protected
> resources, possibly
> concurrently with other readers. Note that down_read may put the calling process
> into an uninterruptible sleep.
>
> Does this mean that kernel will not allow changes to the memory
> buffers(data) in the protected region?
> By chance, if someone try to do a 'a++' between these calls where a is
> global, what will happen?
>
> Thank you making your best effort to clarify my doubts.
>
> Regards,
> Bhanu
>
> On 4/3/08, sahlot arvind <asahlot@xxxxxxxxx> wrote:
> > 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
> > > > >
> > > > >
> > > >
> > > >
> > >
> >
> >
>
--
To unsubscribe from this list: send an email with
"unsubscribe kernelnewbies" to ecartis@xxxxxxxxxxxx
Please read the FAQ at http://kernelnewbies.org/FAQ
