threads and kernel

threads and kernel

[Shriramana Sharma]

Hello, my knowledgeable friends! :)

1.

As I understand it, the kernel is always running and whenever an app 
asks for a system resource the kernel does the needful. However, in my 
process tree I see no process named linux or kernel. I only see the init 
process at the root of the tree. Does the init process represent the kernel?

2.

When an app does a system call, would some form of IPC between the 
process of that app and the kernel process (assuming there is one) be 
involved?

3.

When an application uses a library, the app and the library are 
processed in DIFFERENT threads in which of the following cases:

1. the library is statically linked
2. the library is dynamically linked
3. the library is loaded using dlopen

My guess is "none of the above", am I right?

These are NOT homework questions! :)

Thanks, as always.

Shriramana Sharma.

Re: threads and kernel

[Irfan Habib]

unsubscribe linux-c-programming

Re: threads and kernel

[Steve Graegert]

Hello Shriramana,

your questions can be answered in very great detail and fill whole
books (which has actually happened), so please forgive my brief
answers.

(Comments inline)

On 10/21/07, Shriramana Sharma <samjnaa@gmail.com> wrote:
> Hello, my knowledgeable friends! :)
>
> 1.
>
> As I understand it, the kernel is always running and whenever an app
> asks for a system resource the kernel does the needful. However, in my
> process tree I see no process named linux or kernel. I only see the init
> process at the root of the tree. Does the init process represent the kernel?

When the boot loader has finished loading the kernel image and invoked
startup_32() on x86 systems the kernel spawns the scheduler (PID 0)
and the init process (PID 1) separately.  The scheduler then takes
control over the system as soon as the kernel goes idle and init
starts the /etc/rc.d/rc.sysinit script.

Yes, there is no kernel process, but there are a couple of other
system processes: kflushd, kupdate, kpiod, kswapd, etc.

> 2.
>
> When an app does a system call, would some form of IPC between the
> process of that app and the kernel process (assuming there is one) be
> involved?

Code typically runs in two or more privilege levels.  Linux supports
two levels known as user  mode and kernel mode.  Higher privileged
code can perform operations which impact system performance and
stability like accessing hardware devices, changing the processor
state, enabling/disabling interrupts, etc.

System calls often make use of special CPU instructions that cause the
processor to transfer control to a higher privilege level allowing the
more privileged code to execute.

When a system call is invoked, the process which has invoked is being
interrupted and all the information needed to continue this process is
stored for later use.  Now, the process executes higher privileged
code that determines what to do next from examining the stack of the
less privileged code.  It contains information about the request to be
served by the kernel.  When it is finished, it control is returned to
the program, restoring the saved state and continuing program
execution.

The standard C library provides wrapper functions to make life easier
for developers as the semantic of system calls is system dependent.

> 3.
>
> When an application uses a library, the app and the library are
> processed in DIFFERENT threads in which of the following cases:
>
> 1. the library is statically linked
> 2. the library is dynamically linked
> 3. the library is loaded using dlopen
>
> My guess is "none of the above", am I right?

Runtime linking of libraries is done at the process level.

Dynamic applications, for example, consist of a dynamic executable and
one or more dynamic objects. As part of the initialization and
execution of a dynamic application, runtime linker  ld.so.1, performs
the following functions:

   1. analyze shared object dependencies,
   2. locate and map in these dependencies,
   3. calls initialization functions provided by the shared object,
   4. transfer control to application's main() function.

From this moment on all threads created __within__ the process share
its address space.

As a side note: you can safely use dlopen()  to load shared libraries,
whether or not they depend on libpthread.so, as long as the main
program was initially threaded.  The other way round is dangerous and
mostly not allowed.

> These are NOT homework questions! :)

Yes, I know.  You are a well known member of this list.  No need to apologize.

	\Steve

--

Steve Grägert
DigitalEther.de
-
To unsubscribe from this list: send the line "unsubscribe linux-c-programming" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: threads and kernel

[Benoit Fouet]

Hi,

Steve Graegert wrote:
> As a side note: you can safely use dlopen()  to load shared libraries,
> whether or not they depend on libpthread.so, as long as the main
> program was initially threaded.  The other way round is dangerous and
> mostly not allowed.
>
>   

could you please elaborate a bit on that ? i cannot see why this is
dangerous.

Thanks,

Ben

Re: threads and kernel

[Steve Graegert]

Hi Benoit,

On 10/22/07, Benoit Fouet <benoit.fouet@purplelabs.com> wrote:
> Hi,
>
> Steve Graegert wrote:
> > As a side note: you can safely use dlopen()  to load shared libraries,
> > whether or not they depend on libpthread.so, as long as the main
> > program was initially threaded.  The other way round is dangerous and
> > mostly not allowed.
> >
> >
>
> could you please elaborate a bit on that ? i cannot see why this is
> dangerous.

I was referring to making an application multithreaded at runtime.
Therefore you cannot use dlopen() to dynamically add libpthread.so to
a process when the main program is not __initially threaded__.  By
"initially threaded" I mean that the libpthread.so  library is
initialized at program start, either because the main program links
against libpthread.so directly, or because it links against some other
shared library that links against libpthread.so.

Dynamically changing the process environment from "nonthreaded" to
"threaded" is dangerous and rarely useful (I actually doubt that this
"feature" is useful at all).  Only a few systems implementing POSIX
threads allow the possibility (for example, libc.so on many systems
contains "stub" versions of the POSIX functions that are preempted by
linking with libpthread.so but will not be preempted by later loading
libpthread.so with dlopen()).  In other words, calls to
pthread_create() might fail with ENOSYS, and pthread_mutex_lock()
might continue to succeed without any memory references to the lock.

	\Steve

--

Steve Grägert
DigitalEther.de
-
To unsubscribe from this list: send the line "unsubscribe linux-c-programming" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: threads and kernel

[Benoit Fouet]

Hi Steve,

Steve Graegert wrote:
> Hi Benoit,
>
> On 10/22/07, Benoit Fouet <benoit.fouet@purplelabs.com> wrote:
>   
>> Hi,
>>
>> Steve Graegert wrote:
>>     
>>> As a side note: you can safely use dlopen()  to load shared libraries,
>>> whether or not they depend on libpthread.so, as long as the main
>>> program was initially threaded.  The other way round is dangerous and
>>> mostly not allowed.
>>>
>>>
>>>       
>> could you please elaborate a bit on that ? i cannot see why this is
>> dangerous.
>>     
>
> I was referring to making an application multithreaded at runtime.
> Therefore you cannot use dlopen() to dynamically add libpthread.so to
> a process when the main program is not __initially threaded__.  By
> "initially threaded" I mean that the libpthread.so  library is
> initialized at program start, either because the main program links
> against libpthread.so directly, or because it links against some other
> shared library that links against libpthread.so.
>
> Dynamically changing the process environment from "nonthreaded" to
> "threaded" is dangerous and rarely useful (I actually doubt that this
> "feature" is useful at all).

If i understand correctly what you're saying, you cannot have something
like:

int main(int argc, char *argv[]) {
  /* ... */
  foo = dlopen("bar.so");
  /* use bar.so functions, clean, etc... */
}

if bar.so is multithreaded (and thus, linked to libpthread.so) and you
don't compile your main program with -lpthread option.
did i understand you right ?

this would mean you may need to link against pthread library, just in
case the library(ies) you dlopen might use it ?

>   Only a few systems implementing POSIX
> threads allow the possibility (for example, libc.so on many systems
> contains "stub" versions of the POSIX functions that are preempted by
> linking with libpthread.so but will not be preempted by later loading
> libpthread.so with dlopen()).  In other words, calls to
> pthread_create() might fail with ENOSYS, and pthread_mutex_lock()
> might continue to succeed without any memory references to the lock.
>
>   

Ben

Re: threads and kernel

[Steve Graegert]

Benoit,

On 10/22/07, Benoit Fouet <benoit.fouet@purplelabs.com> wrote:
> Hi Steve,
>
> Steve Graegert wrote:
> > Hi Benoit,
> >
> > On 10/22/07, Benoit Fouet <benoit.fouet@purplelabs.com> wrote:
> >
> >> Hi,
> >>
> >> Steve Graegert wrote:
> >>
> >>> As a side note: you can safely use dlopen()  to load shared libraries,
> >>> whether or not they depend on libpthread.so, as long as the main
> >>> program was initially threaded.  The other way round is dangerous and
> >>> mostly not allowed.
> >>>
> >>>
> >>>
> >> could you please elaborate a bit on that ? i cannot see why this is
> >> dangerous.
> >>
> >
> > I was referring to making an application multithreaded at runtime.
> > Therefore you cannot use dlopen() to dynamically add libpthread.so to
> > a process when the main program is not __initially threaded__.  By
> > "initially threaded" I mean that the libpthread.so  library is
> > initialized at program start, either because the main program links
> > against libpthread.so directly, or because it links against some other
> > shared library that links against libpthread.so.
> >
> > Dynamically changing the process environment from "nonthreaded" to
> > "threaded" is dangerous and rarely useful (I actually doubt that this
> > "feature" is useful at all).
>
> If i understand correctly what you're saying, you cannot have something
> like:
>
> int main(int argc, char *argv[]) {
>   /* ... */
>   foo = dlopen("bar.so");
>   /* use bar.so functions, clean, etc... */
> }
>
> if bar.so is multithreaded (and thus, linked to libpthread.so) and you
> don't compile your main program with -lpthread option.
> did i understand you right ?
>
> this would mean you may need to link against pthread library, just in
> case the library(ies) you dlopen might use it ?

Linking against a multi-threaded library at compile time, turns the
main program into a multi-threaded program even though no use of
threads is being made at all.

	\Steve

--

Steve Grägert
DigitalEther.de
-
To unsubscribe from this list: send the line "unsubscribe linux-c-programming" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: threads and kernel

[Benoit Fouet]

Hi,

Steve Graegert wrote:
> Benoit,
>
> On 10/22/07, Benoit Fouet <benoit.fouet@purplelabs.com> wrote:
>   
>> Hi Steve,
>>
>> Steve Graegert wrote:
>>     
>>> Hi Benoit,
>>>
>>> On 10/22/07, Benoit Fouet <benoit.fouet@purplelabs.com> wrote:
>>>
>>>       
>>>> Hi,
>>>>
>>>> Steve Graegert wrote:
>>>>
>>>>         
>>>>> As a side note: you can safely use dlopen()  to load shared libraries,
>>>>> whether or not they depend on libpthread.so, as long as the main
>>>>> program was initially threaded.  The other way round is dangerous and
>>>>> mostly not allowed.
>>>>>
>>>>>
>>>>>
>>>>>           
>>>> could you please elaborate a bit on that ? i cannot see why this is
>>>> dangerous.
>>>>
>>>>         
>>> I was referring to making an application multithreaded at runtime.
>>> Therefore you cannot use dlopen() to dynamically add libpthread.so to
>>> a process when the main program is not __initially threaded__.  By
>>> "initially threaded" I mean that the libpthread.so  library is
>>> initialized at program start, either because the main program links
>>> against libpthread.so directly, or because it links against some other
>>> shared library that links against libpthread.so.
>>>
>>> Dynamically changing the process environment from "nonthreaded" to
>>> "threaded" is dangerous and rarely useful (I actually doubt that this
>>> "feature" is useful at all).
>>>       
>> If i understand correctly what you're saying, you cannot have something
>> like:
>>
>> int main(int argc, char *argv[]) {
>>   /* ... */
>>   foo = dlopen("bar.so");
>>   /* use bar.so functions, clean, etc... */
>> }
>>
>> if bar.so is multithreaded (and thus, linked to libpthread.so) and you
>> don't compile your main program with -lpthread option.
>> did i understand you right ?
>>
>> this would mean you may need to link against pthread library, just in
>> case the library(ies) you dlopen might use it ?
>>     
>
> Linking against a multi-threaded library at compile time, turns the
> main program into a multi-threaded program even though no use of
> threads is being made at all.
>
>   

i agree, but this was not what i asked.
consider a library foo using threads.
consider a main program bar only linked to dl.
chat you said is that bar cannot use sanely foo functions, because it is
not multithreaded itself, right ?

Ben

Re: threads and kernel

[Steve Graegert]

On 10/22/07, Benoit Fouet <benoit.fouet@purplelabs.com> wrote:
> Hi,
>
> Steve Graegert wrote:
> > Benoit,
> >
> > On 10/22/07, Benoit Fouet <benoit.fouet@purplelabs.com> wrote:
> >
> >> Hi Steve,
> >>
> >> Steve Graegert wrote:
> >>
> >>> Hi Benoit,
> >>>
> >>> On 10/22/07, Benoit Fouet <benoit.fouet@purplelabs.com> wrote:
> >>>
> >>>
> >>>> Hi,
> >>>>
> >>>> Steve Graegert wrote:
> >>>>
> >>>>
> >>>>> As a side note: you can safely use dlopen()  to load shared libraries,
> >>>>> whether or not they depend on libpthread.so, as long as the main
> >>>>> program was initially threaded.  The other way round is dangerous and
> >>>>> mostly not allowed.
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>> could you please elaborate a bit on that ? i cannot see why this is
> >>>> dangerous.
> >>>>
> >>>>
> >>> I was referring to making an application multithreaded at runtime.
> >>> Therefore you cannot use dlopen() to dynamically add libpthread.so to
> >>> a process when the main program is not __initially threaded__.  By
> >>> "initially threaded" I mean that the libpthread.so  library is
> >>> initialized at program start, either because the main program links
> >>> against libpthread.so directly, or because it links against some other
> >>> shared library that links against libpthread.so.
> >>>
> >>> Dynamically changing the process environment from "nonthreaded" to
> >>> "threaded" is dangerous and rarely useful (I actually doubt that this
> >>> "feature" is useful at all).
> >>>
> >> If i understand correctly what you're saying, you cannot have something
> >> like:
> >>
> >> int main(int argc, char *argv[]) {
> >>   /* ... */
> >>   foo = dlopen("bar.so");
> >>   /* use bar.so functions, clean, etc... */
> >> }
> >>
> >> if bar.so is multithreaded (and thus, linked to libpthread.so) and you
> >> don't compile your main program with -lpthread option.
> >> did i understand you right ?
> >>
> >> this would mean you may need to link against pthread library, just in
> >> case the library(ies) you dlopen might use it ?
> >>
> >
> > Linking against a multi-threaded library at compile time, turns the
> > main program into a multi-threaded program even though no use of
> > threads is being made at all.
> >
> >
>
> i agree, but this was not what i asked.
> consider a library foo using threads.
> consider a main program bar only linked to dl.
> chat you said is that bar cannot use sanely foo functions, because it is
> not multithreaded itself, right ?

Basilcally yes, but let me summarize some important points:

Suppose you have an application that is not linked against libpthread,
neither directly nor indirectly (just as you stated earlier).  The
init code used to set up the main program doesn't care about threads,
because it assumes that they won't be used anyway.  Hence you have a
non-threaded program.  The important thing is the init code, not
whether the main program makes call to pthread_* and its siblings or
not.

Now, this non-thread program loads a shared object using dlopen()
which is linked against libpthread, thus resulting in an "abort trap".

I remember Apache to crash with an abort trap when loading mod_perl
although it has been build without errors.  Recompiling apache with
CFLAGS+=-pthread fixed the problem.

Example:

#include <dlfcn.h>
#include <stdio.h>
#include <stdlib.h>

int main(void) {
	void *h;  // the handle

	printf("Trying to load libpthread.so\n");
	h = dlopen("libpthread.so", RTLD_LAZY);
	printf("libpthread.so loaded successfully\n");
	dlclose(h);

	return EXIT_SUCCESS;
}

This can be worked around by linking against libpthread, because this
causes the initialization code used to set up the program to be
overridden.

Considering the previous example, doing:

cc test.c
./a.out

results in a crash. But

cc -lpthread test.c
./a.out

won't. Even

cc test.c
LD_PRELOAD=/usr/lib/libpthread.so ./a.out

will work.  It's the initialization code that matters, not if threads
are used or not.

	\Steve

--

Steve Grägert
DigitalEther.de
-
To unsubscribe from this list: send the line "unsubscribe linux-c-programming" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: threads and kernel

[Benoit Fouet]

Steve Graegert wrote:
> [...]
>
> It's the initialization code that matters, not if threads
> are used or not.
>
>   

ok, thanks for explaining

Ben

Re: threads and kernel

[vibi]

 > "The init code used to set up the main program doesn't care about threads,

 because it assumes that they won't be used anyway."

when is init code linked to the program ,during the compile time or
during the run time?

thanks in advance
regards 
vibi sreenivasan

Re: threads and kernel

[Steve Graegert]

On 10/23/07, vibi <vibi_sreenivasan@cms.com> wrote:
>  > "The init code used to set up the main program doesn't care about threads,
>
>  because it assumes that they won't be used anyway."
>
> when is init code linked to the program ,during the compile time or
> during the run time?

It's being added by the linker at compile time.

	\Steve

--

Steve Grägert
DigitalEther.de
-
To unsubscribe from this list: send the line "unsubscribe linux-c-programming" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: threads and kernel

[vibi]

On Tue, 2007-10-23 at 07:14 +0200, Steve Graegert wrote:
> On 10/23/07, vibi <vibi_sreenivasan@cms.com> wrote:
> >  > "The init code used to set up the main program doesn't care about threads,
> >
> >  because it assumes that they won't be used anyway."
> >
> > when is init code linked to the program ,during the compile time or
> > during the run time?
> 
> It's being added by the linker at compile time.
> 
> 	\Steve

the application you gave earlier is linked without any knowledge of
multi-threading
so 

> cc test.c
> ./a.out

would fail

but you also said 

> cc test.c
> LD_PRELOAD=/usr/lib/libpthread.so ./a.out

will not fail

in both the cases same init code is added at compile time and you also
said that init code determines whether a program is multi-threaded.

So i am a little bit confused because how at run time the init code is
changed.

regards
vibi sreenivasan

> 
> Steve Grägert
> DigitalEther.de
> 

-
To unsubscribe from this list: send the line "unsubscribe linux-c-programming" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: threads and kernel

[Steve Graegert]

On 10/23/07, vibi <vibi_sreenivasan@cms.com> wrote:
> On Tue, 2007-10-23 at 07:14 +0200, Steve Graegert wrote:
> > On 10/23/07, vibi <vibi_sreenivasan@cms.com> wrote:
> > >  > "The init code used to set up the main program doesn't care about threads,
> > >
> > >  because it assumes that they won't be used anyway."
> > >
> > > when is init code linked to the program ,during the compile time or
> > > during the run time?
> >
> > It's being added by the linker at compile time.
> >
> >       \Steve
>
> the application you gave earlier is linked without any knowledge of
> multi-threading
> so
>
> > cc test.c
> > ./a.out
>
> would fail
>
> but you also said
>
> > cc test.c
> > LD_PRELOAD=/usr/lib/libpthread.so ./a.out
>
> will not fail
>
> in both the cases same init code is added at compile time and you also
> said that init code determines whether a program is multi-threaded.
>
> So i am a little bit confused because how at run time the init code is
> changed.

Linkage takes place at compile time and run time.  When starting a
program its execution environment is setup properly including loading
and linking in all libraries (including those specified on the command
line with LD_PRELOAD and at compile time).

The LD_PRELOAD environment variable allows you to load additional
shared libraries at program startup.  The loader ld.so.1, loads the
specified shared libraries as if the program had been linked
explicitly with the shared libraries in LD_PRELOAD before any other
dependents of the program.  At startup time, the loader implicitly
loads one or more libraries, if found, specified in the LD_PRELOAD
environment. It uses the same load order and symbol resolution order
as if the library had been explicitly linked as the first library in
the link line when building the executable.

As a result, at startup the program is multi-threaded when
LD_PRELOAD=/usr/lib/libpthread.so is specified, but if libpthread is
neither specified at compile time nor __before__ startup of the main
program (i.e. LD_PRELOAD) the execution environment is unchanged (not
threaded at all).

This is possible because the init code of the libraries is executed at
before control is transfered to the main program, thus the program is
multi-threaded although libpthread has no been specified at compile
time and no thread-related function calls are made during runtime.

	\Steve

--

Steve Grägert
DigitalEther.de
-
To unsubscribe from this list: send the line "unsubscribe linux-c-programming" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: threads and kernel

[vibi]

On Tue, 2007-10-23 at 08:58 +0200, Steve Graegert wrote:
> On 10/23/07, vibi <vibi_sreenivasan@cms.com> wrote:
> > On Tue, 2007-10-23 at 07:14 +0200, Steve Graegert wrote:
> > > On 10/23/07, vibi <vibi_sreenivasan@cms.com> wrote:
> > > >  > "The init code used to set up the main program doesn't care about threads,
> > > >
> > > >  because it assumes that they won't be used anyway."
> > > >
> > > > when is init code linked to the program ,during the compile time or
> > > > during the run time?
> > >
> > > It's being added by the linker at compile time.
> > >
> > >       \Steve
> >
> > the application you gave earlier is linked without any knowledge of
> > multi-threading
> > so
> >
> > > cc test.c
> > > ./a.out
> >
> > would fail
> >
> > but you also said
> >
> > > cc test.c
> > > LD_PRELOAD=/usr/lib/libpthread.so ./a.out
> >
> > will not fail
> >
> > in both the cases same init code is added at compile time and you also
> > said that init code determines whether a program is multi-threaded.
> >
> > So i am a little bit confused because how at run time the init code is
> > changed.
> 
> Linkage takes place at compile time and run time.  When starting a
> program its execution environment is setup properly including loading
> and linking in all libraries (including those specified on the command
> line with LD_PRELOAD and at compile time).
> 
> The LD_PRELOAD environment variable allows you to load additional
> shared libraries at program startup.  The loader ld.so.1, loads the
> specified shared libraries as if the program had been linked
> explicitly with the shared libraries in LD_PRELOAD before any other
> dependents of the program.  At startup time, the loader implicitly
> loads one or more libraries, if found, specified in the LD_PRELOAD
> environment. It uses the same load order and symbol resolution order
> as if the library had been explicitly linked as the first library in
> the link line when building the executable.
> 
> As a result, at startup the program is multi-threaded when
> LD_PRELOAD=/usr/lib/libpthread.so is specified, but if libpthread is
> neither specified at compile time nor __before__ startup of the main
> program (i.e. LD_PRELOAD) the execution environment is unchanged (not
> threaded at all).
> 
> This is possible because the init code of the libraries is executed at
> before control is transfered to the main program, thus the program is
> multi-threaded although libpthread has no been specified at compile
> time and no thread-related function calls are made during runtime.
> 
> 	\Steve

so init code is just like a stub which is resolved while setting up the
execution environment of the program,ie linkage resolution at load time.

am i understanding correctly.

thanks very much for your help
regards 
vibi sreenivasan
 
> 
> --
> 
> Steve Grägert
> DigitalEther.de
> 

-
To unsubscribe from this list: send the line "unsubscribe linux-c-programming" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: threads and kernel

[Steve Graegert]

On 10/23/07, vibi <vibi_sreenivasan@cms.com> wrote:
> On Tue, 2007-10-23 at 08:58 +0200, Steve Graegert wrote:
> > On 10/23/07, vibi <vibi_sreenivasan@cms.com> wrote:
> > > On Tue, 2007-10-23 at 07:14 +0200, Steve Graegert wrote:
> > > > On 10/23/07, vibi <vibi_sreenivasan@cms.com> wrote:
> > > > >  > "The init code used to set up the main program doesn't care about threads,
> > > > >
> > > > >  because it assumes that they won't be used anyway."
> > > > >
> > > > > when is init code linked to the program ,during the compile time or
> > > > > during the run time?
> > > >
> > > > It's being added by the linker at compile time.
> > > >
> > > >       \Steve
> > >
> > > the application you gave earlier is linked without any knowledge of
> > > multi-threading
> > > so
> > >
> > > > cc test.c
> > > > ./a.out
> > >
> > > would fail
> > >
> > > but you also said
> > >
> > > > cc test.c
> > > > LD_PRELOAD=/usr/lib/libpthread.so ./a.out
> > >
> > > will not fail
> > >
> > > in both the cases same init code is added at compile time and you also
> > > said that init code determines whether a program is multi-threaded.
> > >
> > > So i am a little bit confused because how at run time the init code is
> > > changed.
> >
> > Linkage takes place at compile time and run time.  When starting a
> > program its execution environment is setup properly including loading
> > and linking in all libraries (including those specified on the command
> > line with LD_PRELOAD and at compile time).
> >
> > The LD_PRELOAD environment variable allows you to load additional
> > shared libraries at program startup.  The loader ld.so.1, loads the
> > specified shared libraries as if the program had been linked
> > explicitly with the shared libraries in LD_PRELOAD before any other
> > dependents of the program.  At startup time, the loader implicitly
> > loads one or more libraries, if found, specified in the LD_PRELOAD
> > environment. It uses the same load order and symbol resolution order
> > as if the library had been explicitly linked as the first library in
> > the link line when building the executable.
> >
> > As a result, at startup the program is multi-threaded when
> > LD_PRELOAD=/usr/lib/libpthread.so is specified, but if libpthread is
> > neither specified at compile time nor __before__ startup of the main
> > program (i.e. LD_PRELOAD) the execution environment is unchanged (not
> > threaded at all).
> >
> > This is possible because the init code of the libraries is executed at
> > before control is transfered to the main program, thus the program is
> > multi-threaded although libpthread has no been specified at compile
> > time and no thread-related function calls are made during runtime.
> >
> >       \Steve
>
> so init code is just like a stub which is resolved while setting up the
> execution environment of the program,ie linkage resolution at load time.
>
> am i understanding correctly.

Well, it's not a stub, since it's a very important section of the executable.

The .init section holds executable instructions that contribute to the
process initialization code.  That is, when a program starts to run
the system arranges to execute the code in this section before the
main program entry point (main() in C programs).

The .init and .fini sections have a special purpose.  If a function is
placed in the .init section, the system will execute it before the
main function.  Also the functions placed in the .fini section will be
executed by the system after the main function returns.  This feature
is utilized by compilers to implement global constructors and
destructors in C++.

Also, any shared object file included in the program also has an
opportunity to run its initialization code before the call to the main
program.

	\Steve

--

Steve Grägert
DigitalEther.de
-
To unsubscribe from this list: send the line "unsubscribe linux-c-programming" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: threads and kernel

[Shriramana Sharma]

Steve Graegert wrote:
> your questions can be answered in very great detail and fill whole
> books (which has actually happened), so please forgive my brief
> answers.

Brief answers are sufficient. Thank you. :)

> and the init process (PID 1) separately.  The scheduler then takes
> control over the system as soon as the kernel goes idle and init
> starts the /etc/rc.d/rc.sysinit script.

So would the kernel be "reawakened" by some external event occurring, as
Glynn wrote? I am thinking like -- the kernel is a body of instructions,
just like any other program. So like I do something (type "cp" at a
terminal, for ex) to have the program called "cp" to be processed --
that is, the instructions in it are executed. Similarly when a system
call is made by any program, the instructions contained in the kernel
would be executed. Is this understanding right?

> When a system call is invoked, the process which has invoked is being
> interrupted and all the information needed to continue this process is
> stored for later use.  Now, the process executes higher privileged
> code that determines what to do next from examining the stack of the
> less privileged code.  It contains information about the request to be
> served by the kernel.  When it is finished, it control is returned to
> the program, restoring the saved state and continuing program
> execution.

So technically the kernel instructions would be processed "in" the same
process and thread that makes the system call, albeit with different
privelege, right? Or is the process *making the system call* totally
"paused", as in a "wait" situation when one process waits for another to
finish?

Do I also understand right that the kernel resides in a special section 
of memory the boot loader puts it in? The core of the kernel (apart from 
dynamically loadable kernel modules) is the vmlinuz file sitting in my 
/boot dir, right?

> Yes, I know.  You are a well known member of this list.  No need to apologize.

Oh thanks -- that was very nice of you to say. I only thought -- these
are probably very basic questions for my friends here, and so may seem
like homework questions. :)

Have a nice day, all! :)

Shriramana Sharma.

Re: threads and kernel

[Steve Graegert]

On 10/22/07, Shriramana Sharma <samjnaa@gmail.com> wrote:
> Steve Graegert wrote:
> > your questions can be answered in very great detail and fill whole
> > books (which has actually happened), so please forgive my brief
> > answers.
>
> Brief answers are sufficient. Thank you. :)
>
> > and the init process (PID 1) separately.  The scheduler then takes
> > control over the system as soon as the kernel goes idle and init
> > starts the /etc/rc.d/rc.sysinit script.
>
> So would the kernel be "reawakened" by some external event occurring, as
> Glynn wrote?

Yes, exactly.

> I am thinking like -- the kernel is a body of instructions,
> just like any other program. So like I do something (type "cp" at a
> terminal, for ex) to have the program called "cp" to be processed --
> that is, the instructions in it are executed. Similarly when a system
> call is made by any program, the instructions contained in the kernel
> would be executed. Is this understanding right?

That is basically correct.

> > When a system call is invoked, the process which has invoked is being
> > interrupted and all the information needed to continue this process is
> > stored for later use.  Now, the process executes higher privileged
> > code that determines what to do next from examining the stack of the
> > less privileged code.  It contains information about the request to be
> > served by the kernel.  When it is finished, it control is returned to
> > the program, restoring the saved state and continuing program
> > execution.
>
> So technically the kernel instructions would be processed "in" the same
> process and thread that makes the system call, albeit with different
> privelege, right? Or is the process *making the system call* totally
> "paused", as in a "wait" situation when one process waits for another to
> finish?

Well, no.

Whenever a user program is invoked a new process is created.
Nevertheless, the system call is handled in the kernel's address space
which is made available by a "context switch" (int 0x80) from user
mode to kernel mode.

When a process requests the kernel to do something which is currently
impossible but that may become possible later, the process is put to
sleep and is woken up when the request is more likely to be satisfied.
One of the kernel mechanisms used for this is called a "wait queue".

When a userspace application makes a system call, the arguments are
passed via registers and the application executes "int 0x80" (x86)
instruction. This causes a trap into kernel mode and processor jumps
to system_call entry point in entry.S. What this does is:

   1. Save registers.
   2. Set %ds (data segment) and %es (extra segment) to KERNEL_DS,
allowing the references to be made in the kernel address space.
   3. If the value of %eax (the system call number supposed to serve
the request is stored here) is greater than NR_syscalls (max no. of
system calls, currently 256), fail with ENOSYS error.
   4. Call sys_call_table (initialized at boot up) with syscall_number
argument from %eax. This table (arch/i386/kernel/entry.S) points to
individual system call handlers which will find their arguments on the
stack.
   5. Enter the so called "system call return path" checking if a call
to schedule() is needed, checking for pending signals and if so
handling them.
   6. Check for errors

> Do I also understand right that the kernel resides in a special section
> of memory the boot loader puts it in? The core of the kernel (apart from
> dynamically loadable kernel modules) is the vmlinuz file sitting in my
> /boot dir, right?

Short answer: yes.

Long answer: Linux actually implements a two stage boot process. In
the first stage, the BIOS loads the boot program (Initial Program
Loader) from the hard disk to the memory.  In the second stage, the
boot program loads the operating system kernel vmlinuz into memory and
uncompresses it, since vmlinuz is a compressed kernel image (protected
mode).

When the kernel loads into memory, it performs a memory test.  Most of
the kernel data structures are initialized statically. So it sets
aside a part of memory for kernel use. This part of the memory cannot
be used by any other processes. It also reports the total amount of
physical memory available and sets aside those for the user processes.

Hope that was helpful.

	\Steve

--

Steve Grägert
DigitalEther.de
-
To unsubscribe from this list: send the line "unsubscribe linux-c-programming" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: threads and kernel

[Glynn Clements]

Shriramana Sharma wrote:

> > When a system call is invoked, the process which has invoked is being
> > interrupted and all the information needed to continue this process is
> > stored for later use.  Now, the process executes higher privileged
> > code that determines what to do next from examining the stack of the
> > less privileged code.  It contains information about the request to be
> > served by the kernel.  When it is finished, it control is returned to
> > the program, restoring the saved state and continuing program
> > execution.
> 
> So technically the kernel instructions would be processed "in" the same
> process and thread that makes the system call, albeit with different
> privelege, right? Or is the process *making the system call* totally
> "paused", as in a "wait" situation when one process waits for another to
> finish?

The kernel is a completely different "process" in so far as it has a
separate task descriptor, and thus a different memory layout etc.

The system call is executed in the same "flow" in that the INT-80
instruction causes the CPU to start executing kernel code; after the
system call has completed, control will eventually return to the
calling process at the instruction after the INT-80.

In that sense, it's similar to a function call, but the similarity
largely stops there.

-- 
Glynn Clements <glynn@gclements.plus.com>

Re: threads and kernel

[Glynn Clements]

Shriramana Sharma wrote:

> As I understand it, the kernel is always running

Not in the same sense that a process is "running". Most of the time,
it's "blocked" waiting for some external event to occur and give it
something to do.

> and whenever an app 
> asks for a system resource the kernel does the needful. However, in my 
> process tree I see no process named linux or kernel. I only see the init 
> process at the root of the tree. Does the init process represent the kernel?

No. "init" is /sbin/init. It's a normal process, albeit a fairly
important one.

> When an app does a system call, would some form of IPC between the 
> process of that app and the kernel process (assuming there is one) be 
> involved?

In some ways, a system call is just like a function call. The main
difference is that the kernel code is invoked through a software
interrupt or trap, which causes the code to execute in the kernel's
context rather than the application's context. Apart from having a
completely different memory layout, the kernel code runs with
increased privileges (ring 0 on i386, supervisor mode on 680x0, etc).

If you want to know the details, you'll need to read a reference book
for the particular type of CPU.

> When an application uses a library, the app and the library are 
> processed in DIFFERENT threads in which of the following cases:
> 
> 1. the library is statically linked
> 2. the library is dynamically linked
> 3. the library is loaded using dlopen
> 
> My guess is "none of the above", am I right?

Correct. Many applications don't use threads at all. Even for those
which do, any calls to a library function are executed in the same
thread as the code which call it.

-- 
Glynn Clements <glynn@gclements.plus.com>