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
