Kbase P73663: Which Progress process are multi-threaded?
| Autor |
Progress Software Corporation - Progress |
| Acesso |
Público |
| Publicação |
14/04/2009 |
|
Status: Verified
GOAL:
Is the Progress client multi-threaded ?
GOAL:
Can a Progress client become multi-thread process?
GOAL:
Which Progress process are multi-thread?
GOAL:
Are any Progress programs multi-threaded?
GOAL:
Is Multi-threaded a multi-threaded relationship between the Progress SQL-92 server and client rather than a way for a single task to use multiple CPUs
GOAL:
Is _mprosrv multi-threaded
GOAL:
Is the Progress Client SMP or multiprocessor aware?
GOAL:
Does the progress 4GL client support multi-threaded processing?
FACT(s) (Environment):
All Supported Operating Systems
Progress 9.1x
OpenEdge 10.x
FIX:
There are Progress/OpenEdge utilites that are multi-threaded. At the time of writting;
- the dbtool utility is multi-threaded.
- In OpenEdge 10, the binary dump and Phase 2 of idxbuild process were enhanced for multi-threading. The Progress client is a single threaded application. It does not support multi-threaded applications.
The OpenEdge broker/server process for ABL clients (_mprosrv) is not multi-threaded. It can spawn multiple server processes, each capable of serving multiple clients (which are configurable through the -Mn -Ma database login broker startup parameters). The server processes context switch for each client request and, when returning batches of records, context switch after a number of records have been sent.
The Progress client (_progress, prowin32) being single threaded means therefore that an ABL application cannot be designed to process multiple tasks at the same time. Depending on requirements, an AppServer and asynchronous calls could be used instead. The AppServer Broker (Server) being a java process - spawns several threads which the OS may allocate accross several CPU's. Each AppServer (Agent) being _progress however, will be assigned by the OS to a CPU but not accross CPU's.
Since Progress 9.1D, the OpenEdge SQL Server processes provide a thread per connection. A new thread is created whenever a new connection is established. The thread is terminated when the connection ends. This will still however run as one sqlsrv2 process (for each remote server spawned) on one CPU.
Only the Enterprise Database Server has specific parameter switches and tools to help better utilize/optimize a multiprocessor environment (for example -spin), however it is the underlying operating system which is responsible for directing processes to processors. iow: we would expect the number of processes evenly distributed accross available CPU's as opposed to being limited to one sector (unless the OS has explicitly been configured to do so).