We will provide at least a minimal implementation for Threads. Note: It should go right to the metal and utilize everything that native Linux has to offer.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hmm, right to the metal uhh? I take it you do not mean simply wrapping the posix threads implementation that is now a standard slice of glibc for linux? Which threading implementation model will you adopt? one-to-one (the status quo), one-to-many (not appealing and there is already a very good pthread-compatible api that runs all threads in userland, GNU Pth), or many-to-many (what much of the linux community including me look forward to as a major enhancement to multi-threaded linux programming). Unfortunately this means writing your own userland scheduler with the addition of requiring the implementation to perform better on context switches for mutex and condition var operations--this would greatly enhance Java and other heavily multi-threaded applications performance if patched into glibc-linuxthreads, which in my book would be a real significant contribution to the community in general and the project in specific.
Thoughts? Am I on the wrong track here?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
A thread is basically a path of execution through a program. It is also the smallest unit of execution that Linux schedules. A thread consists of a stack, the state of the CPU registers, and an entry in the execution list of the system scheduler. At the implementors discretion, each thread can share all of the process's resources.
A process consists of one or more threads and the code, data, and other resources of a program in memory. Typical program resources are open files, semaphores, and dynamically allocated memory. A program executes when the system scheduler gives one of its threads execution control. The scheduler determines which threads should run and when they should run. Threads of lower priority may have to wait while higher priority threads complete their tasks. On multiprocessor machines, the scheduler can move individual threads to different processors to "balance" the CPU load.
Each thread in a process operates independently. Unless you make them visible to each other, the threads execute individually and are unaware of the other threads in a process. Threads sharing common resources, however, must coordinate their work by using semaphores or another method of interprocess communication. See Requirement 1589-Semaphores for information on synchronization and coordination between threads.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
A thread is basically a path of execution through a program. It is also the smallest unit of execution that
Linux schedules. A thread consists of a stack, the state of the CPU registers, and an entry in the execution
list of the system scheduler. At the implementors discretion, each thread can share all of the process's
resources (Memory, Files, Signals, etc).
A process consists of one or more threads, data, and other resources of a program in memory.
Typical program resources are open files, semaphores, and dynamically allocated memory. A program executes when
the system scheduler gives one of its threads execution control. The scheduler determines which threads should
run and when they should run. Threads of lower priority may have to wait while higher priority threads complete
their tasks. On multiprocessor machines, the scheduler can move individual threads to different processors to
"balance" the CPU load, or providing maximum throughput.
Each thread in a process operates independently. Unless you make them visible to each other, the threads
execute individually and are unaware of the other threads in a process. Threads sharing common resources,
however, must coordinate their work by using semaphores or other methods of interprocess communication. See
Requirement 1589-Semaphores for information on synchronization and coordination between threads.
There are a number of different scenarios where a thread is useful:
Thread Usages
-------------
In this scenario, the main body of the program would like to schedule work to be performed that does not require user interface focus. Some examples:
Reading or writing a file.
Spooling a job to a printer.
Establishing a connection to another machine.
Watching a system resource.
Performing background computations.
The underlying kernel support for the CoreLinux++ Thread is clone().
The CoreLinux++ Thread class shall provide a static method which returns a kernel runtime errno specific to a thread instance
The CoreLinux++ Thread class shall provide a static method which returns the ThreadIdentifier for the caller
The CoreLinux++ Thread instance shall provide the ability to have it's state initialized prior to execution.
The CoreLinux++ Thread instance shall be derived from Synchronized, and as such has a integral mechanism for conducting operations in a safe manner.
The CoreLinux++ Thread instance shall have a unique identifier (ThreadIdentifier).
The CoreLinux++ library shall provide a ThreadDescriptor, which will be maintained by the library throughout the Threads life.
The CoreLinux++ ThreadDescriptor shall contain life, state, and death information.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
A thread is basically a path of execution through a program. It is also the smallest unit of execution that Linux schedules. A thread consists of a stack, the state of the CPU registers, and an entry in the execution list of the system scheduler. At the implementors discretion, each thread can share all of the process's resources (Memory, Files, Signals, etc).
A process consists of one or more threads, data, and other resources of a program in memory. Typical program resources are open files, semaphores, and dynamically allocated memory. A program executes when the system scheduler gives one of its threads execution control. The scheduler determines which threads should run and when they should run. Threads of lower priority may have to wait while higher priority threads complete their tasks. On multiprocessor machines, the scheduler can move individual threads to different processors to "balance" the CPU load, or providing maximum throughput.
Each thread in a process operates independently. Unless you make them visible to each other, the threads execute individually and are unaware of the other threads in a process. Threads sharing common resources, however, must coordinate their work by using semaphores or other methods of interprocess communication. See Requirement 1589-Semaphores for information on synchronization and coordination between threads.
The underlying kernel support for the CoreLinux++ Thread is clone(). This means a number of things:
* The CoreLinux++ thread implementation will scale to Symetrical Multiple Processor (SMP) implementations as the Linux kernel manages scheduling of threads across processors.
* CoreLinux++ thread implementation will expose the options for thread instantiation, such as limiting which resources are available from the spawning process (memory, signals, files, etc.).
Targets for using threads
-------------------------
A number of scenarios make the use of threads desirable, generally anywhere the main body of the program would like to schedule concurrent work to be performed that does not require user interface focus. Some examples:
Reading or writing a file.
Spooling a job to a printer.
Establishing a connection to another machine.
Watching a system resource.
Performing background computations.
CoreLinux Thread Functional Requirements
General Requirements
---------------------
Class Requirements
------------------
The CoreLinux++ Thread class shall provide a static method which returns a kernel runtime errno specific to a thread instance
The CoreLinux++ Thread class shall provide a static method which returns the ThreadIdentifier for the caller
The CoreLinux++ Thread class shall manage all threads created through it's interface
The CoreLinux++ Thread class shall accept a caller defined stack to use.
The CoreLinux++ Thread class shall adjust the created thread top of stack accept a caller defined stack to use.
The CoreLinux++ Thread class shall allocate a default stack for a new thread if one is not specified by the caller.
The CoreLinux++ Thread class shall accept a requests for a default stack allocation size.
The CoreLinux++ Thread class shall provide instrumentation information
The CoreLinux++ Thread class instrumentation shall include the number of threads created count
The CoreLinux++ Thread class instrumentation shall include the number of threads completed count
The CoreLinux++ Thread class instrumentation shall include the number of threads active count
The CoreLinux++ Thread class instrumentation shall include the number of threads blocked count
Instance Requirements
---------------------
The CoreLinux++ Thread instance shall provide the ability to have it's state initialized prior to execution.
The CoreLinux++ Thread instance shall be derived from Synchronized, and as such has a integral mechanism for conducting operations in a safe manner.
The CoreLinux++ Thread instance shall have a unique identifier (ThreadIdentifier).
The CoreLinux++ Thread instance shall support priority and priority class change requests
The CoreLinux++ Thread shall provide a ThreadDescriptor, which will be maintained by the library throughout the Threads life.
The CoreLinux++ ThreadDescriptor shall contain life, state, and death information.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
A thread is basically a path of execution through a program. It is also the smallest unit of execution that Linux schedules. A thread consists of a stack, the state of the CPU registers, and an entry in the execution list of the system scheduler. At the implementors discretion, each thread can share all of the process's resources (Memory, Files, Signals, etc.).
A process consists of one or more threads, data, and other resources of a program in memory. A program executes when the system scheduler gives one of its threads execution control. The scheduler determines which threads should run and when they should run. Threads of lower priority may have to wait while higher priority threads complete their tasks. On multiprocessor machines, the scheduler can move individual threads to different processors to "balance" the CPU load, or providing maximum throughput.
Each thread in a process operates independently. Unless you make them visible to each other, the threads execute individually and are unaware of the other threads in a process. Collectively, the resources a thread references (stack, registers, variables, instructions, etc.) are considered as part of the context for the path of execution. Threads sharing common resources, however, may need to coordinate their work by using semaphores or other methods of interprocess communication. See Requirement 1589-Semaphores for information on synchronization and coordination between threads.
The underlying kernel support for CoreLinux++ functionality, in regards to threads, is clone(). This means a number of things:
* The solution space implementation will scale to Symmetrical Multiple Processor (SMP) implementations as the Linux kernel manages scheduling of threads across processors.
* CoreLinux++ implementation will expose the options for thread instantiation, such as limiting which resources are available from the spawning process (memory, signals, files, etc.).
Targets for using threads
-------------------------
A number of scenarios make the use of threads desirable, generally anywhere the main body of the program would like to schedule concurrent work to be performed that does not require user interface focus. Some examples:
Reading or writing a file.
Spooling a job to a printer.
Establishing a connection to another machine.
Watching a system resource.
Performing background computations.
this is by no means an exhaustive list of what may qualify as "thread-able" work.
CoreLinux Thread Functional Requirements
General Requirements
---------------------
Class Requirements
------------------
The CoreLinux++ Thread class shall provide a static method which returns a kernel runtime errno specific to a thread instance
The CoreLinux++ Thread class shall provide a static method which returns the ThreadIdentifier for the caller.
The CoreLinux++ Thread class shall provide interface which supports starting a thread of execution.
The CoreLinux++ Thread class shall provide interface for specifying variable number of arguments to the thread of execution.
The CoreLinux++ Thread class shall provide interface for specifying a caller defined stack to use.
The CoreLinux++ Thread class shall allocate a default stack for a new thread if one is not specified by the caller.
The CoreLinux++ Thread class shall provide interface for specifying a default stack allocation size.
The CoreLinux++ Thread class shall provide options for creating default stacks in system memory.
The CoreLinux++ Thread class shall manage all threads created through it's interface
The CoreLinux++ Thread class shall create a ThreadContext for each thread it creates.
The CoreLinux++ Thread class shall maintain the ThreadContext on behalf of the caller.
The CoreLinux++ Thread class shall provide the ThreadContext to the caller upon request.
The CoreLinux++ Thread class shall provide a iterator over all the ThreadContexts created through it's interface.
The CoreLinux++ Thread class shall provide instrumentation information.
The CoreLinux++ Thread class instrumentation shall include the number of threads created count.
The CoreLinux++ Thread class instrumentation shall include the number of threads completed count.
The CoreLinux++ Thread class instrumentation shall include the number of threads active count.
The CoreLinux++ Thread class instrumentation shall include the number of threads blocked count.
Context Requirements
--------------------
The CoreLinux++ ThreadContext shall provide the ability to initialize it's state prior to execution.
The CoreLinux++ ThreadContext shall be derived from Synchronized, and as such has a integral mechanism for conducting operations in a safe manner.
The CoreLinux++ ThreadContext shall share the kernel supplied unique identifier (ThreadIdentifier) for the executing thread.
The CoreLinux++ ThreadContext shall contain life, state, and death information throughout the life of the thread, and thereafter.
The CoreLinux++ ThreadContext shall contain the stack of the executing thread.
The CoreLinux++ ThreadContext shall maintain the current priority assignment for a thread.
The CoreLinux++ ThreadContext shall provide interface for determining if a thread is pending execution, active, naturally dead, or excepted.
The CoreLinux++ ThreadContext shall remain in memory until it is requested to be cleaned up.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
A thread is a single, sequential flow of control within a program. It is also the smallest unit of execution that Linux schedules. A thread consists of a stack, the state of the CPU registers, and an entry in the execution list of the system scheduler. At the implementors discretion, each thread can share all of the process's resources (Memory, Files, Signals, etc.).
A process consists of one or more threads, data, and other resources of a program in memory. A multi-threaded application is considered when there is at least one thread in addition to the main thread of the program. A program executes when the system scheduler gives one of its threads execution control. The scheduler determines which threads should run and when they should run. Threads of lower priority may have to wait while higher priority threads complete their tasks. On multiprocessor machines, the scheduler can move individual threads to different processors to "balance" the CPU load, or providing maximum throughput.
Each thread in a process operates independently. Unless you make them visible to each other, the threads execute individually and are unaware of the other threads in a process. Collectively, the resources a thread references (stack, registers, variables, instructions, etc.) are considered as part of the context for the path of execution. Threads sharing common resources, however, may need to coordinate their work by using semaphores or other methods of interprocess communication. See Requirement 1589-Semaphores for information on synchronization and coordination between threads.
The underlying kernel support for CoreLinux++ functionality, in regards to threads, is clone(). This means a number of things:
* The solution space implementation will scale to Symmetrical Multiple Processor (SMP) implementations as the Linux kernel manages scheduling of threads across processors.
* CoreLinux++ implementation will expose the options for thread instantiation, such as limiting which resources are available from the spawning process (memory, signals, files, etc.).
Targets for using threads
-------------------------
A number of scenarios make the use of threads desirable, generally anywhere the main body of the program would like to schedule concurrent work to be performed that does not require user interface focus. Some examples:
Reading or writing a file.
Spooling a job to a printer.
Establishing a connection to another machine.
Watching a system resource.
Performing background computations.
this is by no means an exhaustive list of what may qualify as "thread-able" work.
CoreLinux Thread Functional Requirements
General Requirements
---------------------
Class Requirements
------------------
The CoreLinux++ Thread class shall provide a static method which returns a kernel runtime errno specific to a thread instance
The CoreLinux++ Thread class shall provide a static method which returns the ThreadIdentifier for the caller.
The CoreLinux++ Thread class shall provide interface which supports starting a thread of execution.
The CoreLinux++ Thread class shall provide interface for specifying variable number of arguments to the thread of execution.
The CoreLinux++ Thread class shall provide interface for specifying a caller defined stack to use.
The CoreLinux++ Thread class shall allocate a default stack for a new thread if one is not specified by the caller.
The CoreLinux++ Thread class shall provide interface for specifying a default stack allocation size.
The CoreLinux++ Thread class shall provide options for creating default stacks in system memory.
The CoreLinux++ Thread class shall manage all threads created through it's interface
The CoreLinux++ Thread class shall create a ThreadContext for each thread it creates.
The CoreLinux++ Thread class shall maintain the ThreadContext on behalf of the caller.
The CoreLinux++ Thread class shall provide the ThreadContext to the caller upon request.
The CoreLinux++ Thread class shall provide a iterator over all the ThreadContexts created through it's interface.
The CoreLinux++ Thread class shall provide instrumentation information.
The CoreLinux++ Thread class instrumentation shall include the number of threads created count.
The CoreLinux++ Thread class instrumentation shall include the number of threads completed count.
The CoreLinux++ Thread class instrumentation shall include the number of threads active count.
The CoreLinux++ Thread class instrumentation shall include the number of threads blocked count.
The CoreLinux++ Thread class shall provide the interface for setting a threads priority.
The CoreLinux++ Thread class shall provide the interface for getting a threads priority.
The CoreLinux++ Thread class shall provide the interface for sending a signal to a thread.
The CoreLinux++ Thread class shall handle all signals for a thread by default.
The CoreLinux++ Thread class shall provide the interface for setting a threads signal mask.
The CoreLinux++ Thread class shall provide the interface for getting a threads signal mask.
The CoreLinux++ Thread class shall provide the interface for instructing a thread to exit immediately.
The CoreLinux++ Thread class shall provide the interface for a caller to block until a thread completes execution.
Context Requirements
--------------------
The CoreLinux++ ThreadContext shall provide the ability to initialize it's state prior to execution.
The CoreLinux++ ThreadContext shall be derived from Synchronized, and as such has a integral mechanism for conducting operations in a safe manner.
The CoreLinux++ ThreadContext shall share the kernel supplied unique identifier (ThreadIdentifier) for the executing thread.
The CoreLinux++ ThreadContext shall contain life, state, and death information throughout the life of the thread, and thereafter.
The CoreLinux++ ThreadContext shall contain the stack of the executing thread.
The CoreLinux++ ThreadContext shall maintain the current priority assignment for a thread.
The CoreLinux++ ThreadContext shall provide interface for determining if a thread is pending execution, active, naturally dead, or excepted.
The CoreLinux++ ThreadContext shall remain in memory until it is requested to be cleaned up.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Thread use case and analysis diagrams created and posted to the web.
The analysis diagram is a abstraction of the operating systems relationships to threads and resources. It will serve as the underlying model for a C++ implementation.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I have started on the implementation. In the true OO way it will put a iteration back into design given the quirks I am bound to hit with Linux specifics and nuances not considered.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
While still lacking major capabilities such as Signal management, callbacks, etc. A working implementation is available in CVS. I will be testing and possibly adding more for the 0.4.13 release which will go out Mar 26 2000 US.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
CoreLinux++ should provide a Thread abstraction.
We will provide at least a minimal implementation for Threads. Note: It should go right to the metal and utilize everything that native Linux has to offer.
Hmm, right to the metal uhh? I take it you do not mean simply wrapping the posix threads implementation that is now a standard slice of glibc for linux? Which threading implementation model will you adopt? one-to-one (the status quo), one-to-many (not appealing and there is already a very good pthread-compatible api that runs all threads in userland, GNU Pth), or many-to-many (what much of the linux community including me look forward to as a major enhancement to multi-threaded linux programming). Unfortunately this means writing your own userland scheduler with the addition of requiring the implementation to perform better on context switches for mutex and condition var operations--this would greatly enhance Java and other heavily multi-threaded applications performance if patched into glibc-linuxthreads, which in my book would be a real significant contribution to the community in general and the project in specific.
Thoughts? Am I on the wrong track here?
Could you open this discussion up in the mailing list?
Threads have a dependency on Semaphores.
CoreLinux++ Thread Requirement (1588 ) Draft - 0.1
------------------------------------------------------------------------
A thread is basically a path of execution through a program. It is also the smallest unit of execution that Linux schedules. A thread consists of a stack, the state of the CPU registers, and an entry in the execution list of the system scheduler. At the implementors discretion, each thread can share all of the process's resources.
A process consists of one or more threads and the code, data, and other resources of a program in memory. Typical program resources are open files, semaphores, and dynamically allocated memory. A program executes when the system scheduler gives one of its threads execution control. The scheduler determines which threads should run and when they should run. Threads of lower priority may have to wait while higher priority threads complete their tasks. On multiprocessor machines, the scheduler can move individual threads to different processors to "balance" the CPU load.
Each thread in a process operates independently. Unless you make them visible to each other, the threads execute individually and are unaware of the other threads in a process. Threads sharing common resources, however, must coordinate their work by using semaphores or another method of interprocess communication. See Requirement 1589-Semaphores for information on synchronization and coordination between threads.
CoreLinux++ Thread Requirement (1588) Draft - 0.2
-------------------------------------------------
A thread is basically a path of execution through a program. It is also the smallest unit of execution that
Linux schedules. A thread consists of a stack, the state of the CPU registers, and an entry in the execution
list of the system scheduler. At the implementors discretion, each thread can share all of the process's
resources (Memory, Files, Signals, etc).
A process consists of one or more threads, data, and other resources of a program in memory.
Typical program resources are open files, semaphores, and dynamically allocated memory. A program executes when
the system scheduler gives one of its threads execution control. The scheduler determines which threads should
run and when they should run. Threads of lower priority may have to wait while higher priority threads complete
their tasks. On multiprocessor machines, the scheduler can move individual threads to different processors to
"balance" the CPU load, or providing maximum throughput.
Each thread in a process operates independently. Unless you make them visible to each other, the threads
execute individually and are unaware of the other threads in a process. Threads sharing common resources,
however, must coordinate their work by using semaphores or other methods of interprocess communication. See
Requirement 1589-Semaphores for information on synchronization and coordination between threads.
There are a number of different scenarios where a thread is useful:
Thread Usages
-------------
In this scenario, the main body of the program would like to schedule work to be performed that does not require user interface focus. Some examples:
Reading or writing a file.
Spooling a job to a printer.
Establishing a connection to another machine.
Watching a system resource.
Performing background computations.
The underlying kernel support for the CoreLinux++ Thread is clone().
The CoreLinux++ Thread class shall provide a static method which returns a kernel runtime errno specific to a thread instance
The CoreLinux++ Thread class shall provide a static method which returns the ThreadIdentifier for the caller
The CoreLinux++ Thread instance shall provide the ability to have it's state initialized prior to execution.
The CoreLinux++ Thread instance shall be derived from Synchronized, and as such has a integral mechanism for conducting operations in a safe manner.
The CoreLinux++ Thread instance shall have a unique identifier (ThreadIdentifier).
The CoreLinux++ library shall provide a ThreadDescriptor, which will be maintained by the library throughout the Threads life.
The CoreLinux++ ThreadDescriptor shall contain life, state, and death information.
CoreLinux++ Thread Requirement (1588) Draft - 0.3
-------------------------------------------------
A thread is basically a path of execution through a program. It is also the smallest unit of execution that Linux schedules. A thread consists of a stack, the state of the CPU registers, and an entry in the execution list of the system scheduler. At the implementors discretion, each thread can share all of the process's resources (Memory, Files, Signals, etc).
A process consists of one or more threads, data, and other resources of a program in memory. Typical program resources are open files, semaphores, and dynamically allocated memory. A program executes when the system scheduler gives one of its threads execution control. The scheduler determines which threads should run and when they should run. Threads of lower priority may have to wait while higher priority threads complete their tasks. On multiprocessor machines, the scheduler can move individual threads to different processors to "balance" the CPU load, or providing maximum throughput.
Each thread in a process operates independently. Unless you make them visible to each other, the threads execute individually and are unaware of the other threads in a process. Threads sharing common resources, however, must coordinate their work by using semaphores or other methods of interprocess communication. See Requirement 1589-Semaphores for information on synchronization and coordination between threads.
The underlying kernel support for the CoreLinux++ Thread is clone(). This means a number of things:
* The CoreLinux++ thread implementation will scale to Symetrical Multiple Processor (SMP) implementations as the Linux kernel manages scheduling of threads across processors.
* CoreLinux++ thread implementation will expose the options for thread instantiation, such as limiting which resources are available from the spawning process (memory, signals, files, etc.).
Targets for using threads
-------------------------
A number of scenarios make the use of threads desirable, generally anywhere the main body of the program would like to schedule concurrent work to be performed that does not require user interface focus. Some examples:
Reading or writing a file.
Spooling a job to a printer.
Establishing a connection to another machine.
Watching a system resource.
Performing background computations.
CoreLinux Thread Functional Requirements
General Requirements
---------------------
Class Requirements
------------------
The CoreLinux++ Thread class shall provide a static method which returns a kernel runtime errno specific to a thread instance
The CoreLinux++ Thread class shall provide a static method which returns the ThreadIdentifier for the caller
The CoreLinux++ Thread class shall manage all threads created through it's interface
The CoreLinux++ Thread class shall accept a caller defined stack to use.
The CoreLinux++ Thread class shall adjust the created thread top of stack accept a caller defined stack to use.
The CoreLinux++ Thread class shall allocate a default stack for a new thread if one is not specified by the caller.
The CoreLinux++ Thread class shall accept a requests for a default stack allocation size.
The CoreLinux++ Thread class shall provide instrumentation information
The CoreLinux++ Thread class instrumentation shall include the number of threads created count
The CoreLinux++ Thread class instrumentation shall include the number of threads completed count
The CoreLinux++ Thread class instrumentation shall include the number of threads active count
The CoreLinux++ Thread class instrumentation shall include the number of threads blocked count
Instance Requirements
---------------------
The CoreLinux++ Thread instance shall provide the ability to have it's state initialized prior to execution.
The CoreLinux++ Thread instance shall be derived from Synchronized, and as such has a integral mechanism for conducting operations in a safe manner.
The CoreLinux++ Thread instance shall have a unique identifier (ThreadIdentifier).
The CoreLinux++ Thread instance shall support priority and priority class change requests
The CoreLinux++ Thread shall provide a ThreadDescriptor, which will be maintained by the library throughout the Threads life.
The CoreLinux++ ThreadDescriptor shall contain life, state, and death information.
CoreLinux++ Thread Requirement (1588) Draft - 0.4
-------------------------------------------------
A thread is basically a path of execution through a program. It is also the smallest unit of execution that Linux schedules. A thread consists of a stack, the state of the CPU registers, and an entry in the execution list of the system scheduler. At the implementors discretion, each thread can share all of the process's resources (Memory, Files, Signals, etc.).
A process consists of one or more threads, data, and other resources of a program in memory. A program executes when the system scheduler gives one of its threads execution control. The scheduler determines which threads should run and when they should run. Threads of lower priority may have to wait while higher priority threads complete their tasks. On multiprocessor machines, the scheduler can move individual threads to different processors to "balance" the CPU load, or providing maximum throughput.
Each thread in a process operates independently. Unless you make them visible to each other, the threads execute individually and are unaware of the other threads in a process. Collectively, the resources a thread references (stack, registers, variables, instructions, etc.) are considered as part of the context for the path of execution. Threads sharing common resources, however, may need to coordinate their work by using semaphores or other methods of interprocess communication. See Requirement 1589-Semaphores for information on synchronization and coordination between threads.
The underlying kernel support for CoreLinux++ functionality, in regards to threads, is clone(). This means a number of things:
* The solution space implementation will scale to Symmetrical Multiple Processor (SMP) implementations as the Linux kernel manages scheduling of threads across processors.
* CoreLinux++ implementation will expose the options for thread instantiation, such as limiting which resources are available from the spawning process (memory, signals, files, etc.).
Targets for using threads
-------------------------
A number of scenarios make the use of threads desirable, generally anywhere the main body of the program would like to schedule concurrent work to be performed that does not require user interface focus. Some examples:
Reading or writing a file.
Spooling a job to a printer.
Establishing a connection to another machine.
Watching a system resource.
Performing background computations.
this is by no means an exhaustive list of what may qualify as "thread-able" work.
CoreLinux Thread Functional Requirements
General Requirements
---------------------
Class Requirements
------------------
The CoreLinux++ Thread class shall provide a static method which returns a kernel runtime errno specific to a thread instance
The CoreLinux++ Thread class shall provide a static method which returns the ThreadIdentifier for the caller.
The CoreLinux++ Thread class shall provide interface which supports starting a thread of execution.
The CoreLinux++ Thread class shall provide interface for specifying variable number of arguments to the thread of execution.
The CoreLinux++ Thread class shall provide interface for specifying a caller defined stack to use.
The CoreLinux++ Thread class shall allocate a default stack for a new thread if one is not specified by the caller.
The CoreLinux++ Thread class shall provide interface for specifying a default stack allocation size.
The CoreLinux++ Thread class shall provide options for creating default stacks in system memory.
The CoreLinux++ Thread class shall manage all threads created through it's interface
The CoreLinux++ Thread class shall create a ThreadContext for each thread it creates.
The CoreLinux++ Thread class shall maintain the ThreadContext on behalf of the caller.
The CoreLinux++ Thread class shall provide the ThreadContext to the caller upon request.
The CoreLinux++ Thread class shall provide a iterator over all the ThreadContexts created through it's interface.
The CoreLinux++ Thread class shall provide instrumentation information.
The CoreLinux++ Thread class instrumentation shall include the number of threads created count.
The CoreLinux++ Thread class instrumentation shall include the number of threads completed count.
The CoreLinux++ Thread class instrumentation shall include the number of threads active count.
The CoreLinux++ Thread class instrumentation shall include the number of threads blocked count.
Context Requirements
--------------------
The CoreLinux++ ThreadContext shall provide the ability to initialize it's state prior to execution.
The CoreLinux++ ThreadContext shall be derived from Synchronized, and as such has a integral mechanism for conducting operations in a safe manner.
The CoreLinux++ ThreadContext shall share the kernel supplied unique identifier (ThreadIdentifier) for the executing thread.
The CoreLinux++ ThreadContext shall contain life, state, and death information throughout the life of the thread, and thereafter.
The CoreLinux++ ThreadContext shall contain the stack of the executing thread.
The CoreLinux++ ThreadContext shall maintain the current priority assignment for a thread.
The CoreLinux++ ThreadContext shall provide interface for determining if a thread is pending execution, active, naturally dead, or excepted.
The CoreLinux++ ThreadContext shall remain in memory until it is requested to be cleaned up.
CoreLinux++ Thread Requirement (1588) Draft - 0.5
-------------------------------------------------
A thread is a single, sequential flow of control within a program. It is also the smallest unit of execution that Linux schedules. A thread consists of a stack, the state of the CPU registers, and an entry in the execution list of the system scheduler. At the implementors discretion, each thread can share all of the process's resources (Memory, Files, Signals, etc.).
A process consists of one or more threads, data, and other resources of a program in memory. A multi-threaded application is considered when there is at least one thread in addition to the main thread of the program. A program executes when the system scheduler gives one of its threads execution control. The scheduler determines which threads should run and when they should run. Threads of lower priority may have to wait while higher priority threads complete their tasks. On multiprocessor machines, the scheduler can move individual threads to different processors to "balance" the CPU load, or providing maximum throughput.
Each thread in a process operates independently. Unless you make them visible to each other, the threads execute individually and are unaware of the other threads in a process. Collectively, the resources a thread references (stack, registers, variables, instructions, etc.) are considered as part of the context for the path of execution. Threads sharing common resources, however, may need to coordinate their work by using semaphores or other methods of interprocess communication. See Requirement 1589-Semaphores for information on synchronization and coordination between threads.
The underlying kernel support for CoreLinux++ functionality, in regards to threads, is clone(). This means a number of things:
* The solution space implementation will scale to Symmetrical Multiple Processor (SMP) implementations as the Linux kernel manages scheduling of threads across processors.
* CoreLinux++ implementation will expose the options for thread instantiation, such as limiting which resources are available from the spawning process (memory, signals, files, etc.).
Targets for using threads
-------------------------
A number of scenarios make the use of threads desirable, generally anywhere the main body of the program would like to schedule concurrent work to be performed that does not require user interface focus. Some examples:
Reading or writing a file.
Spooling a job to a printer.
Establishing a connection to another machine.
Watching a system resource.
Performing background computations.
this is by no means an exhaustive list of what may qualify as "thread-able" work.
CoreLinux Thread Functional Requirements
General Requirements
---------------------
Class Requirements
------------------
The CoreLinux++ Thread class shall provide a static method which returns a kernel runtime errno specific to a thread instance
The CoreLinux++ Thread class shall provide a static method which returns the ThreadIdentifier for the caller.
The CoreLinux++ Thread class shall provide interface which supports starting a thread of execution.
The CoreLinux++ Thread class shall provide interface for specifying variable number of arguments to the thread of execution.
The CoreLinux++ Thread class shall provide interface for specifying a caller defined stack to use.
The CoreLinux++ Thread class shall allocate a default stack for a new thread if one is not specified by the caller.
The CoreLinux++ Thread class shall provide interface for specifying a default stack allocation size.
The CoreLinux++ Thread class shall provide options for creating default stacks in system memory.
The CoreLinux++ Thread class shall manage all threads created through it's interface
The CoreLinux++ Thread class shall create a ThreadContext for each thread it creates.
The CoreLinux++ Thread class shall maintain the ThreadContext on behalf of the caller.
The CoreLinux++ Thread class shall provide the ThreadContext to the caller upon request.
The CoreLinux++ Thread class shall provide a iterator over all the ThreadContexts created through it's interface.
The CoreLinux++ Thread class shall provide instrumentation information.
The CoreLinux++ Thread class instrumentation shall include the number of threads created count.
The CoreLinux++ Thread class instrumentation shall include the number of threads completed count.
The CoreLinux++ Thread class instrumentation shall include the number of threads active count.
The CoreLinux++ Thread class instrumentation shall include the number of threads blocked count.
The CoreLinux++ Thread class shall provide the interface for setting a threads priority.
The CoreLinux++ Thread class shall provide the interface for getting a threads priority.
The CoreLinux++ Thread class shall provide the interface for sending a signal to a thread.
The CoreLinux++ Thread class shall handle all signals for a thread by default.
The CoreLinux++ Thread class shall provide the interface for setting a threads signal mask.
The CoreLinux++ Thread class shall provide the interface for getting a threads signal mask.
The CoreLinux++ Thread class shall provide the interface for instructing a thread to exit immediately.
The CoreLinux++ Thread class shall provide the interface for a caller to block until a thread completes execution.
Context Requirements
--------------------
The CoreLinux++ ThreadContext shall provide the ability to initialize it's state prior to execution.
The CoreLinux++ ThreadContext shall be derived from Synchronized, and as such has a integral mechanism for conducting operations in a safe manner.
The CoreLinux++ ThreadContext shall share the kernel supplied unique identifier (ThreadIdentifier) for the executing thread.
The CoreLinux++ ThreadContext shall contain life, state, and death information throughout the life of the thread, and thereafter.
The CoreLinux++ ThreadContext shall contain the stack of the executing thread.
The CoreLinux++ ThreadContext shall maintain the current priority assignment for a thread.
The CoreLinux++ ThreadContext shall provide interface for determining if a thread is pending execution, active, naturally dead, or excepted.
The CoreLinux++ ThreadContext shall remain in memory until it is requested to be cleaned up.
The SRS for thread (req1588.html) has been checked in and posted on the web. It only contains the introduction at this point.
The SRS for Thread has been updated and posted to the web.
Thread use case and analysis diagrams created and posted to the web.
The analysis diagram is a abstraction of the operating systems relationships to threads and resources. It will serve as the underlying model for a C++ implementation.
The initial design for the CoreLinux++ thread implementation has been posted and checked in.
Mar 23 2000 to web and cvs
I have started on the implementation. In the true OO way it will put a iteration back into design given the quirks I am bound to hit with Linux specifics and nuances not considered.
While still lacking major capabilities such as Signal management, callbacks, etc. A working implementation is available in CVS. I will be testing and possibly adding more for the 0.4.13 release which will go out Mar 26 2000 US.