topic Pthread in Operating System - OpenVMS

Pthread

Mulder_1 — Thu, 18 Jun 2009 15:41:00 GMT

Hi,

There is a multi threaded process running on VMS 7.3-1

Is there any way to determine that the process is a multithreaded (Pthread).

$sh sys/multi does not show that it is a multi thread process.

Is Kthread has anything to do with Pthread ?

Thanks

Re: Pthread

Volker Halle — Thu, 18 Jun 2009 16:04:52 GMT

Mulder,

what problem are you trying to solve ?

You can use SDA to determine, if a process is running pthreads:

$ ANAL/SYS
SDA> SET PROC/IND=
SDA> pthread t

will print following message, if process is not threaded:

Process "CLUSTER_SERVER" (PID 20200087) is not threaded

SDA> SHOW PROC/IMA and look for PTHREAD$RTL

Kernel threads support multiple execution contexts within a single OpenVMS process (since OpenVMS Alpha V7.0). DECthreads (pthread) is a user mode thread manager, kernel threads are the basis for OpenVMS scheduling inside the executive.

The system parameter MULTITHREAD determines the amount of multithreading possible.

Volker.

Re: Pthread

John Gillings — Thu, 18 Jun 2009 20:51:07 GMT

Mulder,

Pthread is really an implementation of "coroutines" - that is, a number of threads of execution which timeshare within a single process. They (obviously) share the same address space and data. Only one thread can execute at a particular time. Thread scheduling is done by the Pthread library within the process. This is usermode, which you could implement yourself without privilege.

Kthread is very different. Each thread has most of the attributes of an independent process. The special thing about the threads is they share the same address space. Scheduling is by the operating system, and, in a multi processor environment, independent threads can execute simultaneously. This cannot be done without privilege.

Kthread threads are therefore visible at the OS level, and are displayed in SHOW SYSTEM with the "M" flag. Processes using Pthreads are not externally visible. You can infer them, as Volker has shown, but realise that the presence of PTHREAD$RTL in the image activation list does not necessarily mean it's in active use.

Re: Pthread

Mulder_1 — Fri, 19 Jun 2009 10:08:01 GMT

Please find the attached....

Also,the server is having only 1 CPU...

Thanks

Re: Pthread

Volker Halle — Fri, 19 Jun 2009 10:11:39 GMT

Yes, this process is running pthreads. As pthreads is a user mode thread manager, you do not need multiple CPUs for multiple threads. The threads will all run (one after the other) on one CPU, scheduled by pthreads.

Is there any problem you want to solve ? Or is this just a question out of pure interest ?

Volker.

Re: Pthread

Mulder_1 — Fri, 19 Jun 2009 10:12:19 GMT

Please ignore the previous attachment...

Thanks

Re: Pthread

Volker Halle — Fri, 19 Jun 2009 10:14:57 GMT

Ignored ;-)

But both attachments to me look quite similar ?!

Volker.

Re: Pthread

Mulder_1 — Fri, 19 Jun 2009 12:07:08 GMT

No there is a genuine problem with application which is using multi-threaded process...

The response received is very poor but system is functioning properly.
No problems with the network has been detected.No errors are found.

Thanks for your time...

Re: Pthread

David Jones_21 — Fri, 19 Jun 2009 12:28:16 GMT

The DECthreads library can schedule its threads as either user-mode or kernel threads depending upon flags in the image header.
By default, kernel threads are disabled for a program but can be enabled at link time with the /threads_enable qualifier. You can also use the threadcp program in sys$update (set command sys$update:threadcp.cld) to examine/modify the flags in an existing executable.

Kernel mode threads are disabled by default because true concurrency tends to expose subtle errors in the threading logic of many pthreads programs. Also, it's frequently the case that the parallelism acheived doesn't outweigh the added overhead of kernel thread scheduling vesus the user mode scheduler.

Re: Pthread

Ian Miller. — Fri, 19 Jun 2009 12:57:03 GMT

You should have a look at the fine manual, in particular

http://h71000.www7.hp.com/doc/73final/6493/6101pro_031.html#vms_appendix

Since when did you have the performance problem and why do you think it has something to do with pthreads?

Re: Pthread

Mulder_1 — Tue, 23 Jun 2009 06:24:44 GMT

This application is newly built and has much to do with i/o.

It is basically a mediator which carries request from end user to the DB server and vice-versa.

The problem is there is a greater delay involve in processing the request.

There aren't any errors found that can point to some other way.

There is only negligible CPU usage involved.
What it looks like there is something wrong with the application.

Thanks

Re: Pthread

H.Becker — Tue, 23 Jun 2009 07:25:04 GMT

Maybe it was already checked and I just don't see it: does the application have "upcalls" enabled?

The mentioned threadcp utility can show it, like
$ set command sys$update:threadcp
$ threadcp/show SYS$COMMON:[SYSUPD]THREADCP.EXE

SYS$COMMON:[SYSUPD]THREADCP.EXE;1
%THREADCP-I-MKT, multiple kernel threads are disabled
%THREADCP-I-UPC, upcalls are disabled
$

You also can use analyze/image and check the EIHD$V_UPCALLS bit (set is enabled).

Re: Pthread

Mulder_1 — Tue, 23 Jun 2009 08:01:39 GMT

Now it has been enabled ...

(10) EIHD$V_MKTHREADS 1

(11) EIHD$V_UPCALLS 1

thanks

Re: Pthread

Mulder_1 — Wed, 24 Jun 2009 08:45:10 GMT

The problem is resolved after enabling the upcalls...

Also, enabling MKT has no effect.

The delay no longer exists.

Thanks