多线程编程经验分享1

li_zhongwen — Thu, 04 Nov 2010 02:02:41 +0000

线程是比进程更小的单位，可以认为进程是由一个或多个线程组成的。现在，绝大部分版本的操作管理命令应该都可以支持多线程技术。据说以前的 400 版本并不支持真正的多线程技术，在 4.2版后才从内核上提供了对多线程的支持。我着重想关于多线程的编程技术。
多线程编程有以下几点特殊性（说得直接就是为什么不使用多线程技术的理由，按理由的充分性，由小到大排列）：
1. 多线程的编程在对 C程序的使用上要特别小心，详细内容见调用 C程序的注意事项。
2. 事务处理的作用范围是 JOB级，或活动作业组级。这也就是说多线程并发时，一个线程的 COMMIT操作可能导致另一个线程也执行了 COMMIT操作。（这是 IBM说的，不是我的猜想）。所以实际上也就可以认为多线程的并发不能支持事务操作。
3. 对于用户的应用程序来说，大部分 C、RPG、RPGLE编写的 PGM和 MODULE都不具备线程安全性，也就是不能被一个进程下的多个线程同时调用，要注意。（不排除是因为某些参数未掌握好，总之目前测试的结果就是如此）同时也基于此，多线程之下程序的复用性，维护性就没有单线程下那么方便和自由。
4. 最后，实际测试多线程的效率，非常令人惊讶来——与多进程并发效率竟然一样。测试方法：读一个 380多万条记录的文件，再根据某个键值去 CHAIN另一个 620多万条记录的文件，仅此而已。根据这个 380多万条记录的文件的某个关键字，拆分成 200多个任务，每个任务只处理自己需要处理的数据。（可以简单的认为每个任务是处理 380w/210条记录吧，其实并非如此）多进程分为 10个进程来处理这 200多个任务，耗时3分钟21秒。多线程分为 8个线程来处理这 200多个任务，耗时3分钟17秒，比上步结果少了 3秒钟，我估计这 3秒就是启动 8个线程比启动 10个 JOB 要少的时间吧。我在多线程里还特地增加了共享了 ODP的处理，也是同样效果。
在交互式作业中，用户登录之后，即是启动了一个 JOB，系统需要为其分配相应的资源。我们可以通过 WRKACTJOB命令查看活动的作业。而由 USER、JOBNAME、JOBID可以定位到唯一的一个 JOB，可以使用各种系统命令，来取得指定 JOB当前的状态（比如说 ACTIVE、MSGW、TIMW等），或者是 JOB的信息（ RTVJOBA），也可以使用各种系统命令来操作 JOB（HOLD，END等）。对 JOB的操作、管理都很直观方便。
在 400系统中，一个 JOB就代表了一个进程，按照我的理解，启动一个 JOB，相当于系统就分配了相应的资源给这个 JOB，JOB自身并不负责运行程序；进程则是用来负责管理这个 JOB下运行的程序（这里的程序应该并不专指可以 CALL的程序，我觉得所有的人机交互应该都是通过程序来完成的，即都是由进程来管理的）。按照上文所说，一个 JOB有且仅有一个进程。所以我个人认为在理解上，似乎没有太大必要将进程与 JOB刻意区分开来。一个进程可以对应多个运行中的程序（比如程序 A调用程序 B，那么当前进程就同时管理着程序 A、B的资源。也正是基于这种原理，所以 400平台上的程序调用，允许有返回数据）。每个进程至少拥有一个线程（任务）来执行程序。
进程是基于 JOB的，我们平时所说的多进程并发，实质上指的也就是多 JOB并发。多 JOB并发的原理较为简单，就是使用 SBMJOB命令提交作业来实现并发处理。通常为了便于管理，会建立专用的子系统，以及专用的 JOBD、JOBQ（这里的专用，只是从应用级别而言，建立的方法并没有特殊的地方），也就是说，需要启动多个 JOB。
线程是程序运行的通道，操作系统通过线程，按照一定顺序去逐步执行程序。所有的程序都拥有至少一个线程，对于多线程的程序而言，每一个线程都是独立于其它的线程运行的。
并不是所有的 JOB都支持多线程（实际上，大部分系统应用中，默认的 JOBD的属性都是不支持多线程）。

中文 » li_zhongwen

多线程编程经验分享1