There are Progress/OpenEdge utilities that are multi-threaded at the time of writing (5/13/2019);
- SQL Server: one thread per client connection
- PASOE Agent: number of threads configurable, first available in OpenEdge 11.5
- DB Server: number of thread configurable, first available in OpenEdge 12.0
- DBTOOL: number of thread configurable when run online.
- In OpenEdge 10, the binary dump and Phase 2 of idxbuild process were enhanced for multi-threading. The binary load process is not multi-threaded.
Since OpenEdge 12, when the database is started with -threadedServer 1, the broker will spawn a threaded database server. The executable name of the threaded database server is _mtprosrv as opposed to _mprosrv for the classic database server. For further information refer to Article Starting the multithreaded database server
Prior to OpenEdge 12.0 the broker/server process for ABL clients (_mprosrv) was not multi-threaded. It can spawn multiple server processes, each capable of serving multiple clients (configurable with 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 AppServer for OpenEdge (PAS for OE) is multi-threaded (tomcat and agent, _mproapsv.exe) which can be configured for multiple session threads.
The Classic AppServer / WebSpeed Broker (Server) being a java process - spawns several threads which the OS may allocate across several CPU's. Each Agent being a Progress client (_progress, _proapsv) however, will be assigned by the OS to a CPU but not across CPU's.
The Progress clients (_proapsv, _progress, prowin32, prowin) are single threaded executables and do not support multi-threaded applications. The Progress client being single threaded means that an ABL application cannot be designed to process multiple tasks at the same time. Depending on requirements, a Classic AppServer and asynchronous calls could be used instead:
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 to help better utilize a multiprocessor environment (for example -spin), however it is the underlying operating system which is responsible for directing processes to processors. Progress expects the operating system to govern evenly distributing the number of processes across available CPU's as opposed to being limited to one sector, unless the OS has explicitly been configured to do so.
