Reentrant code / Critical section / Atomic Section
Reentrant code / Critical section / Atomic Section
am 03.08.2006 08:12:40 von Daniel Rodrick
Hi,
Can some body please confirm my understanding?
"Reentrant code" is a piece of code that could be simultaneously
running by multiple threads of execution. (either via SMP, or via
preemption on uniprocessor machines)
"Critical Section" is a piece of code that can be running by only one
thread of execution at a time ( If one thread enters critical section
on one processor, no other thread will enter critical section, even on
another processor).
"Atomic Section" is a piece of code that if starts running on a
processor, then it can't be preempted untill the atomic section is
exited. (it is however possible that the same atomic section is being
run simultaneously on a different processor by a different thread).
In that sense "Reentrant Code" seems to be just the opposite of
"Critical Section". Is this right?
Thanks,
Dan
--
Kernelnewbies: Help each other learn about the Linux kernel.
Archive: http://mail.nl.linux.org/kernelnewbies/
FAQ: http://kernelnewbies.org/faq/
Re: Reentrant code / Critical section / Atomic Section
am 03.08.2006 08:38:17 von Manoj Awasthi
------=_Part_3721_31876515.1154587097277
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
>
>
> "Reentrant code" is a piece of code that could be simultaneously
> running by multiple threads of execution. (either via SMP, or via
> preemption on uniprocessor machines)
A piece of code is reentrant if, while it is being executed, it can be
re-invoked by itself, or by any other routine, by interrupting the present
execution for a while.
must satisfy conditions for 'reentrancy' of a code:
1. It never modifies itself. That is, the instructions of the program
are never changed. Period. Under any circumstances.
2. Any variables changed by the routine must be allocated to a
particular "instance" of the function's invocation. so if a function is
called from three different threads then its data should get stored in three
different areas of memory.
(by avoiding global/static data access)
> In that sense "Reentrant Code" seems to be just the opposite of
> "Critical Section". Is this right?
No.
Thanks,
>
> Dan
thanks,
-Manoj
--
> Kernelnewbies: Help each other learn about the Linux kernel.
> Archive: http://mail.nl.linux.org/kernelnewbies/
> FAQ: http://kernelnewbies.org/faq/
>
>
------=_Part_3721_31876515.1154587097277
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
"Reentrant code" is a piece of code that could be simultaneously
running by multiple threads of execution. (either via SMP, or via
preemption on uniprocessor machines)
A piece of code is reentrant if, while it is being executed, it can
be re-invoked by itself, or by any other routine, by interrupting
the present execution for a while.
must satisfy conditions for 'reentrancy' of a code:
- It never modifies itself. That is, the instructions of the
program are never changed. Period. Under any circumstances.
- Any variables changed by the routine must be allocated to
a particular "instance" of the function's invocation. so if a function is called from three different threads then its data should get stored in three different areas of memory.
(by avoiding global/static data access)
In that sense "Reentrant Code" seems to be just the opposite of
"Critical Section". Is this right?
No.
Thanks,
Dan
thanks,
-Manoj
--
Kernelnewbies: Help each other learn about the Linux kernel.
Archive:
------=_Part_3721_31876515.1154587097277--
--
Kernelnewbies: Help each other learn about the Linux kernel.
Archive: http://mail.nl.linux.org/kernelnewbies/
FAQ: http://kernelnewbies.org/faq/
Re: Reentrant code / Critical section / Atomic Section
am 03.08.2006 09:46:49 von Miguel Angel Alvarez
Daniel Rodrick escribi=F3:
> Hi,
>
> Can some body please confirm my understanding?
>
> "Reentrant code" is a piece of code that could be simultaneously
> running by multiple threads of execution. (either via SMP, or via
> preemption on uniprocessor machines)
Not exactly... A "reentrant code" is a piece of code that is prepared to =
be accesed simultaneously by multiple threads of execution. The keyword=20
is to be prepared.
>
> "Critical Section" is a piece of code that can be running by only one
> thread of execution at a time ( If one thread enters critical section
> on one processor, no other thread will enter critical section, even on
> another processor).
"Critical section" is a piece of code that can cause (for example) race=20
conditions in case of being accesed simultaneously by multiple threads=20
of execution. Critical sections should therefor be protected against =
this.
>
> "Atomic Section" is a piece of code that if starts running on a
> processor, then it can't be preempted untill the atomic section is
> exited. (it is however possible that the same atomic section is being
> run simultaneously on a different processor by a different thread).
More or less.
>
> In that sense "Reentrant Code" seems to be just the opposite of
> "Critical Section". Is this right?
I would not consider them as opposite.
>
> Thanks,
>
> Dan
>
> --=20
> Kernelnewbies: Help each other learn about the Linux kernel.
> Archive: http://mail.nl.linux.org/kernelnewbies/
> FAQ: http://kernelnewbies.org/faq/
>
>
>
Miguel =C1ngel=20
=20
----------------------------------------- PLEASE NOTE =
-------------------------------------------
This message, along with any attachments, may be confidential or legally =
privileged.=20
It is intended only for the named person(s), who is/are the only =
authorized recipients.
If this message has reached you in error, kindly destroy it without =
review and notify the sender immediately.
Thank you for your help.
=B5SysCom uses virus scanning software but excludes any liability for =
viruses contained in any attachment.
=20
------------------------------------ ROGAMOS LEA ESTE TEXTO =
-------------------------------
Este mensaje y sus anexos pueden contener informaci=F3n confidencial y/o =
con derecho legal.=20
Est=E1 dirigido =FAnicamente a la/s persona/s o entidad/es rese=F1adas =
como =FAnico destinatario autorizado.
Si este mensaje le hubiera llegado por error, por favor elim=EDnelo sin =
revisarlo ni reenviarlo y notif=EDquelo inmediatamente al remitente. =
Gracias por su colaboraci=F3n. =20
=B5SysCom utiliza software antivirus, pero no se hace responsable de los =
virus contenidos en los ficheros anexos.
--
Kernelnewbies: Help each other learn about the Linux kernel.
Archive: http://mail.nl.linux.org/kernelnewbies/
FAQ: http://kernelnewbies.org/faq/
Re: Reentrant code / Critical section / Atomic Section
am 03.08.2006 20:32:13 von Rahul Iyer
On Thu, 2006-08-03 at 09:46 +0200, Miguel Angel Alvarez wrote:
> Daniel Rodrick escribió:
> > Hi,
> >
> > Can some body please confirm my understanding?
> >
> > "Reentrant code" is a piece of code that could be simultaneously
> > running by multiple threads of execution. (either via SMP, or via
> > preemption on uniprocessor machines)
> Not exactly... A "reentrant code" is a piece of code that is prepared to
> be accesed simultaneously by multiple threads of execution. The keyword
> is to be prepared.
> >
> > "Critical Section" is a piece of code that can be running by only one
> > thread of execution at a time ( If one thread enters critical section
> > on one processor, no other thread will enter critical section, even on
> > another processor).
> "Critical section" is a piece of code that can cause (for example) race
> conditions in case of being accesed simultaneously by multiple threads
> of execution. Critical sections should therefor be protected against this.
> >
> > "Atomic Section" is a piece of code that if starts running on a
> > processor, then it can't be preempted untill the atomic section is
> > exited. (it is however possible that the same atomic section is being
> > run simultaneously on a different processor by a different thread).
> More or less.
> >
> > In that sense "Reentrant Code" seems to be just the opposite of
> > "Critical Section". Is this right?
> I would not consider them as opposite.
Opposite is sort of an odd word. While I can see where you get that
thought from, a better way of thinking about it is that in both cases,
you run the risk of the procedure being executed simultaneously. What
you do to handle this is the essence of the difference.
In the case of reentrant code, you make all state in the code "local",
i.e every instance of execution has it's own copy of the state
(variables on the stack being one particular example of this, there are
others). In a critical section, you realize that you cannot make the
state local, and so you uise some sort of mutual exclusion scheme.
Of course, there is also the additional case in reentrant code that the
code can be called by itself.
-rahul
>
> >
> > Thanks,
> >
> > Dan
> >
> > --
> > Kernelnewbies: Help each other learn about the Linux kernel.
> > Archive: http://mail.nl.linux.org/kernelnewbies/
> > FAQ: http://kernelnewbies.org/faq/
> >
> >
> >
> Miguel Ángel
>
> ----------------------------------------- PLEASE NOTE -------------------------------------------
> This message, along with any attachments, may be confidential or legally privileged.
> It is intended only for the named person(s), who is/are the only authorized recipients.
> If this message has reached you in error, kindly destroy it without review and notify the sender immediately.
> Thank you for your help.
> µSysCom uses virus scanning software but excludes any liability for viruses contained in any attachment.
>
> ------------------------------------ ROGAMOS LEA ESTE TEXTO -------------------------------
> Este mensaje y sus anexos pueden contener información confidencial y/o con derecho legal.
> Está dirigido únicamente a la/s persona/s o entidad/es reseñadas como único destinatario autorizado.
> Si este mensaje le hubiera llegado por error, por favor elimínelo sin revisarlo ni reenviarlo y notifíquelo inmediatamente al remitente. Gracias por su colaboración.
> µSysCom utiliza software antivirus, pero no se hace responsable de los virus contenidos en los ficheros anexos.
>
> --
> Kernelnewbies: Help each other learn about the Linux kernel.
> Archive: http://mail.nl.linux.org/kernelnewbies/
> FAQ: http://kernelnewbies.org/faq/
>
--
Kernelnewbies: Help each other learn about the Linux kernel.
Archive: http://mail.nl.linux.org/kernelnewbies/
FAQ: http://kernelnewbies.org/faq/