![]() |
| Home > Operational Systems > |
comp.os.chorus Frequently Asked Questions (FAQ) |
Section 2 of 2 - Prev - Next
OO techniques are used in the implementation of the microkernel, but the
API exported by the microkernel is a traditional procedure call based
interface (like UNIX).
5. OS Personalities
================
5.1. OS personalities available on top of CHORUS?
-------------------------------------------
Chorus Systems has developed the following personalties:
- SVR4.0
- SVR3.2
- SCO ODT 3.0
- BSD4.3
- object-oriented (CHORUS/COOL)
- POSIX real-time (POSIX 1003.1b/.1c, former .4/.4a)
Others have developed, or are developing, personalities for SVR4.2 MP,
UNICOS, MacOS, CHILL, ESTEREL, TINA DPE, and a number of (proprietary)
real-time OSs.
5.2. CHORUS/MiX V.3.2
----------------
* What is the link between a u_thread and a kernel thread?
A u_thread is an abstraction, created by the CHORUS/MiX V.3.2
subsystem, on top of the microkernel threads (like a UNIX process
is created on top of a CHORUS actor). Each u_thread is mapped 1-1
to a microkernel thread. A u_thread has some UNIX-specific attributes,
like signal context, which is managed at the CHORUS/MiX subsystem
level, as an added value w.r.t. a microkernel thread.
* Which synchronisation primitives are offered to u_threads?
Sempahores and mutexes.
* Do u_threads support Thread Specific Data?
Yes, through the threadsafe C library (c_threadPrivate(3CT),
c_getPrivate(3CT)). These functions are in fact built on top of the
software registers described for the kernel threads (cf 4.1).
* How are u_threads scheduled?
By the microkernel, just like any other thread.
If one want to implement N user level threads on top of 1 kernel
thread, he need a user level scheduler in some kind of run-time
library (just like an Ada run-time schedules multiple Ada tasks
within one Ada program).
* Is there a way to calculate the size of a u_thread stack?
For dynamic calculation, the best approach is probably to fill
the stack you allocate with a specific pattern, and then at
run-time (or at thread termination) control which part of the
stack still contains the pattern. This allows to calculate
which part of the initial stack has (not) been used.
To detect a stack overflow, the classical approach is to surround
the stack by some chunks of memory that are mapped read-only.
* Is it better to put the thread stack in the data segment or in
the heap area?
The only advantage of putting it on the heap is that the corresponding
memory can be allocated (and freed) dynamically, according to the
application's run-time behaviour and needs. If you allocate it as
data, the corresponding memory is always allocated, even if your
thread doesn't exist yet/anymore.
* What are the differences between an u_thread and a c_thread?
The c_threadXxx(3CT) interface is a library, built upon the
u_threadXxx(2C) interface, and is inspired by early drafts of
the POSIX pthreads interface (POSIX 1003.4a, later renamed to
.1c). It offers a higher level interface than u_threadXxx(2C),
e.g.:
- when creating a c_thread the library creates the stack
for you, while for a u_thread you have to allocate the
stack yourself,
- there is a routine allowing one c_thread to wait for the
termination of another c_thread (c_threadJoin),
- there are routines to allocate and access per c_thread
private global data.
5.3. CHORUS/COOL-ORB
---------------
* How can I write an CORBA::Any to a file and reading it back
from file without any knowledge about the type?
Reply from on July 25th:
The idea is to fill an area of memory with the any value. The
memory must be filled in the same way COOL builds its
communication messages. Once the memory image is built, you
simply have to write it. On the same idea you can read back
the any. With this scheme, you don't need to cope with the
type of the any (and you may also not have it).
I've written a small persistent generic distributed database
on top of CHORUS/COOL ORB. It uses this technique which works
very well. (This is not CORBA but... it's cool)
Here is how you could write:
CORBA_Any any = ...
long size = ::marshalSize(any);
COOL_ComBufDesc buffer(size);
buffer <<= any;
write(fd, buffer.buffer(), size);
Here is how you could read:
struct stat st;
fstat(fd, &st);
COOL_ComBufDesc buffer(st.st_size);
read(fd, buffer.buffer(), st.st_size);
CORBA_Any any;
buffer >>= any;
* Array/sequences manipulation with CHORUS/COOL.
From Mon Sep 2, 1996:
Here is the solution for COOL ORB. With COOL you can take
the address of the first element of the array and use it as the
beginning of the buffer holding the sequence. For example:
// IDL:
typedef sequence OctetSeq;
// C++
OctetSeq* seq = ...; // Passed to the server implementation
// CORBA [] operator returns a reference to the first element
CORBA_Octet& o = (*seq)[0];
// Convert to a pointer and you get the begining of the buffer
CORBA_Octet* p = &o;
You can then optimize the extraction of your data...
* list of platforms supported for CHORUS/COOL?
For an up to date list you can look at the chorus web site at
in the COOL section. The list of
platforms supported by CHORUS/COOL r3.1 is the following:
+----------------------------------------------------------------+
| System | Compiler | Type |
|----------------------------------------------------------------|
| AIX 2.3 | gcc 2.7.2 g++ | mono-threaded |
|----------------------------------------------------------------|
| ClassiX r2.3 for i386at | Dev System r1.1| multi-threaded|
|----------------------------------------------------------------|
| ClassiX r2.3 for MVME167 | Dev System r3.1| multi-threaded|
|----------------------------------------------------------------|
| ClassiX r3.0 for i386at | Dev System r4.0| multi-threaded|
|----------------------------------------------------------------|
| Fusion r2 | SCO C++ 3.1.1 | multi-threaded|
|----------------------------------------------------------------|
| Linux 1.2 | gcc 2.7.2 g++ | mono-threaded |
|----------------------------------------------------------------|
| SCO OpenDesktop 3.0 | SCO C++ 3.1.1 | mono-threaded |
| ---------------------------------|
| | gcc 2.7.2 g++ | mono-threaded |
|----------------------------------------------------------------|
| SCO OpenServer 5.0 | SCO C++ 3.1.1 | mono-threaded |
| ---------------------------------|
| | gcc 2.7.2 g++ | mono-threaded |
|----------------------------------------------------------------|
| Solaris 2.5 | Sparc C++ V4.1 | mono-threaded |
| ---------------------------------|
| | Sparc C++ V4.1 | multi-threaded|
| ---------------------------------|
| | gcc 2.7.2 g++ | mono-threaded |
|----------------------------------------------------------------|
| SunOS 4.1.3 |Sparc C++ V2.0.1| mono-threaded |
| ---------------------------------|
| | gcc 2.7.2 g++ | mono-threaded |
| ---------------------------------|
| |Sparc C++ V4.0.1| mono-threaded |
|----------------------------------------------------------------|
|Windows NT, Windows 95 | Visual C++ 4.0 | mono-threaded |
| ---------------------------------|
| | Visual C++ 4.0 | multi-threaded|
+----------------------------------------------------------------+
* Implementation of COOL_Mutex and COOL_Sem?
Reply from on April 7, 1997:
COOL_Mutex/COOL_Sem are based on the underlying operating system
primitives. That is: mutexGet/mutexRel/semP/semV on CHORUS/OS,
mutex_lock/mutex_unlock/sema_wait/sema_post on Solaris 2.5, and others
on Windows etc...
* How to compile the demo examples of CHORUS/COOL-ORB r4.1 for
debugging purposes?
You must use: make CXXDEBUGFLAGS="-g -O"
* We are using Orbix 2.2 on NT 4.0, and want to create many CORBA objects
per process (at least several thousands to tens of thousands).
From our tests it seems that the time it takes to allocate such objects
is in linear relation to the number of objects.
Has anyone tackled this problem successfully ? Do other ORBs have a
more efficient solution to this problem ?
:
In COOL ORB, the registration depends on the OA that you are using.
The standard OA proposed by COOL uses a hash table for this. This scales
quite well. You can imagine to provide a new OA that registers in a binary
tree (balanced tree would be even better).
To support billions of objects, you should have a look at the Variable
Sized Object Reference feature that COOL ORB supports. A single servant
can be used by many objects: the object reference always refers to the
same servant BUT it also contains additional data which is specific to
the object. Have a look at the 'simpleTree' demo which illustrates a
binary tree and only one servant for referencing all the nodes. Your
tree can contain billions of nodes, you will always have a single servant.
In the next release, COOL ORB will propose a new OA that supports compounds
of servants. This will allow you to register many servants (any type) in
a single registration call to the OA.
Note that beside the performance aspect that you are facing, there is a
memory problem too. Each time you register a servant, the OA needs to
allocate some memory to record it. If you want to support billions of
servants, you must consider this. Having a single servant for implementing
many objects is a first way to reduce the memory usage. Using the
compounds OA is another way.
5.4. CHORUS/ClassiX
---------------
* I am trying to write an experimental network protocol on top of
CHORUS/Classix and found that I get Segmentation fault...
:
Wrong Imakefile: the ndm library is missing in the libs part of the
ClassiXSupProgramTarget macro.
As the actor is a relocatable supervisor actor, the ndmGetMajMin routine
is left undefined in the binary, leading to the segmentation fault.
In you Imakefile you should have:
SRCS = hello.c
LIBS = $(MERGEDIR)/lib/ndmlib/ndmlib.s.a ClassiXSupLibs
ClassiXSupProgramTarget(hello, hello.o, , $(LIBS), ClassiXReloc)
DependTarget()
6. Other software
================
* We are looking for a ISAM file library or a lightweight database
(in terms of storage, runtime overhead and price!) running under CHORUS
(or under BSD UNIX 4.2 if the source code is available).
So far, I found two candidate libraries. The first one is the famous
C-ISAM; However Informix doesn't sell this product anymore (at least not
in Germany). The second one is called CQL++ of Machine Independent
Software Corporation, Scottsdale, AZ. Has anyone heard of it or even
used it in a software project, respectively?
:
Mix Software (Richardson, Texas) also sells for *cheap* an ISAM
database library using b+tree indexing. Source is available,
and the package includes a nice manual describing the library.
See http://www.mixsoftware.com/product/database.htm
Section 2 of 2 - Prev - Next
| Back to category Operational Systems - Use Smart Search |
| Home - Smart Search - About the project - Feedback |
© allanswers.org | Terms of use