CLORB - Multi-Threaded operation

Introduction
LispSupport
InputOutputPolicies
RunningORB

Introduction

LennartStaflin, 9 June 2006 (created 9 June 2006)

not tagging

no tags

CLORB now has some limited support for multi-threaded operation. The I/O can be run using multiple threads for reading sockets. CORBA calls, i.e. client operation, can be done from multiple threads. You can dedicate a thread to call (op:run orb), this thread will also handle the server side, request processing. Alternatively there is a clorb specific method to where the reading threads does response decoding and put incoming requests on a queue for a special dispatcher thread that does the server processing.

LispSupport

LennartStaflin, 9 June 2006 (created 9 June 2006)

not tagging

no tags

Lisp systems supporting multi-threaded CLORB:

OpenMCL 1.1 (need fairly bleeding edge version)
MCL 5.0
SBCL (compiled with sb-thread on linux)

InputOutputPolicies

LennartStaflin, 9 June 2006 (created 7 June 2006)

not tagging

no tags

There are two major variations

Select based
Multi-threaded

A minor variation is wether writes are blocking or non-blocking. Unless all CORBA activity is done in one thread, You need the multi-threaded I/O.

The I/O Policy is decided by the class of the io-system in use and stored in the variable *io-system*. When the orb is initialized the io-system is instantiated with the class stored in *io-system-default-class*. There are four classes that can be used (see also fig):

io-system-select	Select based I/O
io-system-select-blocking-write	Select based I/O with blocking writes
io-system-mt-blocking-write	Multi-threaded I/O with blocking writes
io-system-mt-non-blocking-write	Multi-threaded I/O with non-blocking writes

It is probably easier to use the blocking write systems. The select base I/O with non-blocking writes only works if the system dependent parts implement non-blocking write and currently non of the ports do. The multi-threaded non-blocking write is achived by having a separate ThreadPool for writes.

io-system-select-blocking-write

This class has a synchronization lock, a listener-process, an event handler and a read queue.

It will create a thread to listen for incoming connections. The read queue is a queue and a ThreadPool. That might not be the best solution but I had an implementation of such a queue already done. The thread pool can be given an upper bound for the number of threads created. After that connections will be queued up to be read (thats kind fo stupid, I know).

When a read is finnished the event handler if any will be called, if there is no event handler or if the handler returns nil a event will be put on the io-systems' event queue, where it will be read by (op:run orb) or (op:perform_work orb).

RunningORB

LennartStaflin, 7 June 2006 (created 7 June 2006)

not tagging

no tags

(clorb::bg-run)

Starts a thread to dispatch incoming requests. Configures the io-system to directly process completed reads in the reader threads. Then returns. The orb is now fully operational.

Precondition: a multi-threaded io-system selected, the ORB is initiated and the POA has been setup, i.e. the RootPOA has been accessed.

This replaces (op:run orb).

Alternatively the standard (op:run orb) or (op:perform_work orb) can be used. In this case reader threads will queue events on completed read, the thread running op:run will then do the rest, it will also dispatch incoming requests.

[[Introduction]]\nLispSupport\nInputOutputPolicies\nRunningORB\n

There are two major variations\n* Select based\n* Multi-threaded\nA minor variation is wether writes are blocking or non-blocking. Unless all CORBA activity is done in one thread, You need the multi-threaded I/O. \n\nThe I/O Policy is decided by the class of the io-system in use and stored in the variable {{{*io-system*}}}. When the orb is initialized the io-system is instantiated with the class stored in {{{*io-system-default-class*}}}. There are four classes that can be used (see also [[fig|io-system.png]]):\n\n|io-system-select |Select based I/O |\n|io-system-select-blocking-write |Select based I/O with blocking writes |\n|io-system-mt-blocking-write |Multi-threaded I/O with blocking writes |\n|io-system-mt-non-blocking-write |Multi-threaded I/O with non-blocking writes |\n\nIt is probably easier to use the blocking write systems. The select base I/O with non-blocking writes only works if the system dependent parts implement non-blocking write and currently non of the ports do. The multi-threaded non-blocking write is achived by having a separate ThreadPool for writes.\n\n!!io-system-select-blocking-write\nThis class has a synchronization lock, a listener-process, an event handler and a read queue.\n\nIt will create a thread to listen for incoming connections. The read queue is a queue and a ThreadPool. That might not be the best solution but I had an implementation of such a queue already done. The thread pool can be given an upper bound for the number of threads created. After that connections will be queued up to be read (thats kind fo stupid, I know).\n\nWhen a read is finnished the event handler if any will be called, if there is no event handler or if the handler returns nil a event will be put on the io-systems' event queue, where it will be read by {{{(op:run orb)}}} or {{{(op:perform_work orb)}}}.\n\n\n

CLORB now has some limited support for multi-threaded operation. The I/O can be run using multiple threads for reading sockets. CORBA calls, i.e. client operation, can be done from multiple threads. You can dedicate a thread to call {{{(op:run orb)}}}, this thread will also handle the server side, request processing. Alternatively there is a clorb specific method to where the reading threads does response decoding and put incoming requests on a queue for a special dispatcher thread that does the server processing.\n

Lisp systems supporting multi-threaded CLORB:\n* ~OpenMCL 1.1 (need fairly bleeding edge version)\n* MCL 5.0\n* SBCL (compiled with sb-thread on linux)\n

[[Introduction]]\nLispSupport\nInputOutputPolicies\nRunningORB\n

(clorb::bg-run)\n\nStarts a thread to dispatch incoming requests. Configures the io-system to directly process completed reads in the reader threads. Then returns. The orb is now fully operational.\n\nPrecondition: a multi-threaded io-system selected, the ORB is initiated and the POA has been setup, i.e. the RootPOA has been accessed.\n\nThis replaces (op:run orb).\n\nAlternatively the standard (op:run orb) or (op:perform_work orb) can be used. In this case reader threads will queue events on completed read, the thread running op:run will then do the rest, it will also dispatch incoming requests.\n

~Multi-Threaded operation\n

CLORB

/***\nPlace your custom CSS here\n***/\n/*{{{*/\n.subtitle {\n font-size: 1.1em;\n}\n\n/*}}}*/\n