allanswers.org - comp.os.chorus Frequently Asked Questions (FAQ)

 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

LiveInternet