pthreadslinux

Ⅰ JVM線程與linux內核線程的映射(關系)

Linux從內核2.6開始使用NPTL（Native POSIX Thread Library）支持，但這時線程本質上還輕量級進程。 Native POSIX Thread Library（NPTL）是Linux內核中實踐POSIX Threads標準的庫。POSIX線程（英語：POSIX Threads，常被縮寫為Pthreads）是POSIX的線程標准，定義了創建和操縱線程的一套API。實現POSIX 線程標準的庫常被稱作Pthreads

Pthreads定義了一套C語言的類型、函數與常量，它以pthread.h頭文件和一個線程庫實現。

Pthreads API中大致共有100個函數調用，全都以"pthread_"開頭，並可以分為四類：

線程管理，例如創建線程，等待(join)線程，查詢線程狀態等。
互斥鎖（Mutex）：創建、摧毀、鎖定、解鎖、設置屬性等操作
條件變數（Condition Variable）：創建、摧毀、等待、通知、設置與查詢屬性等操作
使用了互斥鎖的線程間的同步管理

Java里的線程是由JVM來管理的，它如何對應到操作系統的線程是由JVM的實現來確定的。Linux 2.6上的HotSpot使用了NPTL機制， JVM線程跟內核輕量級進程有一一對應的關系 。線程的調度完全交給了操作系統內核，當然jvm還保留一些策略足以影響到其內部的線程調度，舉個例子，在linux下，只要一個Thread.run就會調用一個fork產生一個線程。

Java線程在Windows及Linux平台上的實現方式，現在看來，是內核線程的實現方式。這種方式實現的線程，是直接由操作系統內核支持的——由內核完成線程切換，內核通過操縱調度器（Thread Scheler）實現線程調度，並將線程任務反映到各個處理器上。內核線程是內核的一個分身。程序一般不直接使用該內核線程，而是使用其高級介面，即輕量級進程

創建用戶級線程

Ⅱ linux中查看進程命令ps aux和ps -ef

Linux下顯示系統進程的命令ps，最常用的有ps -ef 和ps aux。這兩個到底有什麼區別呢？兩者沒太大差別，討論這個問題，要追溯到Unix系統中的兩種風格，System V風格和BSD 風格，ps aux最初用到Unix Style中，而ps -ef被用在System V Style中，兩者輸出略有不同。現在的大部分Linux系統都是可以同時使用這兩種方式的。

ps -ef 是用標準的格式顯示進程的、其格式如下： 

其中各列的內容意思如下 

UID //用戶ID、但輸出的是用戶名 

PID //進程的ID 

PPID //父進程ID 

C //進程佔用CPU的百分比 

STIME //進程啟動到現在的時間 

TTY //該進程在那個終端上運行，若與終端無關，則顯示? 若為pts/0等，則表示由網路連接主機進程。 

CMD //命令的名稱和參數

ps aux 是用BSD的格式來顯示、其格式如下： 

同ps -ef 不同的有列有 

USER //用戶名 

%CPU //進程佔用的CPU百分比 

%MEM //佔用內存的百分比 

VSZ //該進程使用的虛擬內存量（KB） 

RSS //該進程佔用的固定內存量（KB）（駐留中頁的數量） 

STAT //進程的狀態 

START //該進程被觸發啟動時間 

TIME //該進程實際使用CPU運行的時間

其中STAT狀態位常見的狀態字元有 

D //無法中斷的休眠狀態（通常 IO 的進程）； uninterruptible sleep (usually IO)不可中斷 

R //正在運行可中在隊列中可過行的； 

S //處於休眠狀態； 

T //停止或被追蹤； traced or stopped 

W //進入內存交換 （從內核2.6開始無效）； 

X //死掉的進程 （基本很少見）； 

Z //僵屍進程；  a defunct (」zombie」) process

< //優先順序高的進程 

N //優先順序較低的進程 

L //有些頁被鎖進內存； 

s //進程的領導者（在它之下有子進程）； 

l //多線程，克隆線程（使用 CLONE_THREAD, 類似 NPTL pthreads）； 

+ //位於後台的進程組；

Ⅲ linux pthread 信號量 佔用資源嗎

glibc提供的pthread互斥信號量可以用在進程內部，也可以用在進程間，可以在初始化時通過pthread_mutexattr_setpshared介面設置該信號量屬性，表示是進程內還是進程間。進程內的使用較為簡單，本文的總結主要是針對進程間的，進程內的也可以參考，其代碼實現原理是類似的。
一、實現原理
pthread mutex的實現是非常輕量級的，採用原子操作+futex系統調用。
在沒有競爭的情況下，即鎖空閑時，任務獲取信號量只需要通過原子操作鎖的狀態值，把值置為佔有，再記錄其他一些俄信息（owner，計數，如果使能回收功能則串入任務的信號量回收鏈表等），然後就返回了。
如果在獲取鎖時發現被佔用了，如果調用者需要睡眠等待，這時候會觸發futex系統調用，由內核繼續處理，內核會讓調用任務睡眠，並在適當時候喚醒（超時或者鎖狀態為可用）。
佔用鎖的任務釋放鎖時，如果沒有任務等待這把鎖，只需要把鎖狀態置為空閑即可。如果發現有其他任務在等待此鎖，則觸發futex系統調用，由內核喚醒等待任務。
由此可見，在沒有競爭的情況下，mutex只需要在用戶態操作鎖狀態值，無須陷入內核，是非常高效的。
獲取到鎖的任務沒有陷入內核，那麼當鎖支持優先順序翻轉時，高優先順序任務等待這把鎖，正常處理必須提升佔用鎖的任務優先順序。內核又是怎麼知道是哪個任務佔用了鎖呢？實現上，復用了鎖的狀態值，該值在空閑態時為0，非空閑態則保存了鎖的持有者ID，即PID,內核態通過PID就知道是那個任務了。
二、內核對鎖的管理
內核維護了一個hash鏈表，每把鎖都被插入到hash鏈表中去，hash值的計算如下（參考get_futex_key)：1，如果是進程內的鎖，則通
過鎖的虛擬地址+任務mm指針值+鎖在頁內偏移；2，如果是進程間的鎖，則會獲取鎖虛擬地址對應物理地址的page描述符，由page描述符構造
hash值。
這樣計算的原因是進程間的鎖在各個進程內虛擬地址可能是不同的，但都映射到同一個物理地址，對應同一個page描述符。所以，內
核使用它來定位是否同一個鎖。
這里對進程間互斥鎖計算hash值的方法，給進程間共享鎖的使用設置了一個隱患條件。下面描述這個問題。

三、進程間互斥信號量的使用限制：必須在系統管理的內存上定義mutex結構，而不能在用戶reserved的共享內存上定義mutex結構。
鎖要實現進程間互斥，必須各個進程都能看到這個鎖，因此，鎖結構必須放在共享內存上。
獲取系統的共享內存通過System V的API介面創建：shmget, shmat,shmdt。但是shmget的參數需要一個id值，各進程映射同一塊共享內存需要同樣的ID值。如果各個進程需要共享的共享內存比較多，如幾千上萬個，ID值如果管理？shmget的man幫助和一些示例代碼給出的是通過ftok函數把一個文件轉為ID值（實際就是把文件對應的INODE轉為ID值），但實際應用中，如果需要的共享內存個數較多，難道創建成千上萬個文件來使用？而且怎麼保證文件在進程的生命周期內不會被刪除或者重建？
當時開發的系統還存在另外一種共享內存，就是我們通過remap_pfn_range實現的，自己管理了這塊內存的申請釋放。申請介面參數為字元串，相同的字元串表示同一塊內存。因此，傾向於使用自己管理的共享內存存放mutex結構。但在使用中，發現這種方法達不到互斥的效果。為什麼？
原因是自己管理的共享內存在內核是通過remap_pfn_range實現的，內核會把這塊內存置為reserved，表示非內核管理，獲取鎖的HASH值時，查找不到page結構，返回失敗了。最後的解決方法還是通過shmget申請共享內存，但不是通過ftok獲取ID，而是通過字元串轉為ID值並處理沖突。

四、進程間互斥信號量回收問題。
假設進程P1獲取了進程間信號量，異常退出了，還沒有釋放信號量，這時候其他進程想來獲取信號量，能獲取的到嗎？
或者進程P1獲取了信號量後，其他進程獲取不到進入了睡眠後，P1異常退出了，誰來負責喚醒睡眠的進程？
好在系統設計上已經考慮了這一點。
只要在信號量初始化時調用pthread_mutexattr_setrobust_np設置支持信號量回收機制，然後，在獲取信號量時，如果原來佔有信號量的進程退出了，系統將會返回EOWNERDEAD，判斷是這個返回值後，調用pthread_mutex_consistent_np完成信號量owner的切換工作即可。
其原理如下：
任務創建時，會注冊一個robust list（用戶態鏈表）到內核的任務控制塊TCB中期，獲取了信號量時，會把信號量掛入鏈表。進程復位時，內核會遍歷此鏈表（內核必須非常小心，因為此時的鏈表信息可能不可靠了，可不能影響到內核），置上ownerdead的標志到鎖狀態，並喚醒等待在此信號量鏈表上的進程。
五、pthread介面使用說明
pthread_mutex_init: 根據指定的屬性初始化一個mutex，狀態為空閑。
pthread_mutex_destroy: 刪除一個mutex
pthread_mutex_lock/trylock/timedlock/unlock: 獲取鎖、釋放鎖。沒有競爭關系的情況下在用戶態只需要置下鎖的狀態值即返回了，無須陷入內核。但是timedlock的入參為超時時間，一般需要調用系統API獲取，會導致陷入內核，性能較差，實現上，可先trylock，失敗了再timedlock。
pthread_mutexattr_init:配置初始化
pthread_mutexattr_destroy:刪除配置初始化介面申請的資源
pthread_mutexattr_setpshared:設置mutex是否進程間共享
pthread_mutexattr_settype:設置類型，如遞歸調用，錯誤檢測等。
pthread_mutexattr_setprotocol:設置是否支持優先順序翻轉
pthread_mutexattr_setprioceiling:設置獲取信號量的任務運行在最高優先順序。
每個set介面都有對應的get介面。

六、pthread結構變數說明

struct __pthread_mutex_s
{
int __lock; ----31bit:這個鎖是否有等待者；30bit：這個鎖的owner是否已經掛掉了。其他bit位：0鎖狀態空閑，非0為持有鎖的任務PID；
unsigned int __count; ----獲取鎖的次數，支持嵌套調用，每次獲取到鎖值加1，釋放減1。
int __owner; ----鎖的owner
unsigned int __nusers; ----使用鎖的任務個數，通常為1（被佔用）或0（空閑）
int __kind;----鎖的屬性，如遞歸調用，優先順序翻轉等。
int __spins; ----SMP下，嘗試獲取鎖的次數，盡量不進入內核。
__pthread_list_t __list; ----把鎖插入回收鏈表，如果支持回收功能，每次獲取鎖時要插入任務控制塊的回收鏈表。
}__data;

Ⅳ Linux 權能綜述

為了執行許可權檢查，傳統的 UNIX 實現區分兩種類型的進程：特權進程（其有效用戶 ID 為0，稱為超級用戶或 root），和非特權用戶（其有效 UID 非0）。特權進程繞過所有的內核許可權檢查，而非特權進程受基於進程的認證信息（通常是：有效 UID，有效 GID，和補充組列表）的完整許可權檢查的支配。

自內核 2.2 版本開始，Linux 將傳統上與超級用戶關聯的特權分為幾個單元，稱為 capabilities （權能），它們可以被獨立的啟用或禁用。權能是每個線程的屬性。

下面的列表展示了 Linux 上實現的權能，以及每種權能允許的操作或行為：

權能的完整實現需要：

在內核 2.6.24 之前，只有前兩個要求能夠滿足；自內核 2.6.24 開始，所有三個要求都能滿足。

每個線程具有三個包含零個或多個上面的權能的權能集合：

A child created via fork(2) inherits copies of its parent's capability sets. See below for a discussion of the treatment of capabilities ring execve(2).

Using capset(2), a thread may manipulate its own capability sets (see below).

Since Linux 3.2, the file /proc/sys/kernel/cap_last_cap exposes the numerical value of the highest capability supported by the running kernel; this can be used to determine the highest bit that may be set in a capability set.

Since kernel 2.6.24, the kernel supports associating capability sets with an executable file using setcap(8). The file capability sets are stored in an extended attribute (see setxattr(2)) named security.capability. Writing to this extended attribute requires the CAP_SETFCAP capability. The file capability sets, in conjunction with the capability sets of the thread, determine the capabilities of a thread after an execve(2).

The three file capability sets are:

During an execve(2), the kernel calculates the new capabilities of the process using the following algorithm:

其中：

A privileged file is one that has capabilities or has the set-user-ID or set-group-ID bit set.

In order to provide an all-powerful root using capability sets, ring an execve(2):

The upshot of the above rules, combined with the capabilities transformations described above, is that when a process execve(2)s a set-user-ID-root program, or when a process with an effective UID of 0 execve(2)s a program, it gains all capabilities in its permitted and effective capability sets, except those masked out by the capability bounding set. This provides semantics that are the same as those provided by traditional UNIX systems.

The capability bounding set is a security mechanism that can be used to limit the capabilities that can be gained ring an execve(2). The bounding set is used in the following ways:

Note that the bounding set masks the file permitted capabilities, but not the inherited capabilities. If a thread maintains a capability in its inherited set that is not in its bounding set, then it can still gain that capability in its permitted set by executing a file that has the capability in its inherited set.

Depending on the kernel version, the capability bounding set is either a system-wide attribute, or a per-process attribute.

In kernels before 2.6.25, the capability bounding set is a system-wide attribute that affects all threads on the system. The bounding set is accessible via the file /proc/sys/kernel/cap-bound. (Confusingly, this bit mask parameter is expressed as a signed decimal number in /proc/sys/kernel/capbound.)

Only the init process may set capabilities in the capability bounding set; other than that, the superuser (more precisely: programs with the CAP_SYS_MODULE capability) may only clear capabilities from this set.

On a standard system the capability bounding set always masks out the CAP_SETPCAP capability. To remove this restriction (dangerous!), modify the definition of CAP_INIT_EFF_SET in include/linux/capability.h and rebuild the kernel.

The system-wide capability bounding set feature was added to Linux starting with kernel version 2.2.11.

From Linux 2.6.25, the capability bounding set is a per-thread attribute. (There is no longer a systemwide capability bounding set.)

The bounding set is inherited at fork(2) from the thread's parent, and is preserved across an execve(2).

A thread may remove capabilities from its capability bounding set using the prctl(2) PR_CAPBSET_DROP operation, provided it has the CAP_SETPCAP capability. Once a capability has been dropped from the bounding set, it cannot be restored to that set. A thread can determine if a capability is in its bounding set using the prctl(2) PR_CAPBSET_READ operation.

Removing capabilities from the bounding set is supported only if file capabilities are compiled into the kernel. In kernels before Linux 2.6.33, file capabilities were an optional feature configurable via the CONFIG_SECURITY_FILE_CAPABILITIES option. Since Linux 2.6.33, the configuration option has been removed and file capabilities are always part of the kernel. When file capabilities are compiled into the kernel, the init process (the ancestor of all processes) begins with a full bounding set. If file capabilities are not compiled into the kernel, then init begins with a full bounding set minus CAP_SETPCAP, because this capability has a different meaning when there are no file capabilities.

Removing a capability from the bounding set does not remove it from the thread's inherited set. However it does prevent the capability from being added back into the thread's inherited set in the future.

To preserve the traditional semantics for transitions between 0 and nonzero user IDs, the kernel makes the following changes to a thread's capability sets on changes to the thread's real, effective, saved set, and filesystem user IDs (using setuid(2), setresuid(2), or similar):

If a thread that has a 0 value for one or more of its user IDs wants to prevent its permitted capability set being cleared when it resets all of its user IDs to nonzero values, it can do so using the prctl(2) PR_SET_KEEPCAPS operation or the SECBIT_KEEP_CAPS securebits flag described below.

A thread can retrieve and change its capability sets using the capget(2) and capset(2) system calls. However, the use of cap_get_proc(3) and cap_set_proc(3), both provided in the libcap package, is preferred for this purpose. The following rules govern changes to the thread capability sets:

Starting with kernel 2.6.26, and with a kernel in which file capabilities are enabled, Linux implements a set of per-thread securebits flags that can be used to disable special handling of capabilities for UID 0 (root). These flags are as follows:

Each of the above "base" flags has a companion "locked" flag. Setting any of the "locked" flags is irreversible, and has the effect of preventing further changes to the corresponding "base" flag. The locked flags are: SECBIT_KEEP_CAPS_LOCKED, SECBIT_NO_SETUID_FIXUP_LOCKED, SECBIT_NOROOT_LOCKED, and SECBIT_NO_CAP_AMBIENT_RAISE.

The securebits flags can be modified and retrieved using the prctl(2) PR_SET_SECUREBITS and PR_GET_SECUREBITS operations. The CAP_SETPCAP capability is required to modify the flags.

The securebits flags are inherited by child processes. During an execve(2), all of the flags are preserved, except SECBIT_KEEP_CAPS which is always cleared.

An application can use the following call to lock itself, and all of its descendants, into an environment where the only way of gaining capabilities is by executing a program with associated file capabilities:

For a discussion of the interaction of capabilities and user namespaces, see user_namespaces(7).

No standards govern capabilities, but the Linux capability implementation is based on the withdrawn POSIX.1e draft standard; see ⟨ http://wt.tuxomania.net/publications/posix.1e/ ⟩.

From kernel 2.5.27 to kernel 2.6.26, capabilities were an optional kernel component, and can be enabled/disabled via the CONFIG_SECURITY_CAPABILITIES kernel configuration option.

The /proc/PID/task/TID/status file can be used to view the capability sets of a thread. The /proc/PID/status file shows the capability sets of a process's main thread. Before Linux 3.8, nonexistent capabilities were shown as being enabled (1) in these sets. Since Linux 3.8, all nonexistent capabilities (above CAP_LAST_CAP) are shown as disabled (0).

The libcap package provides a suite of routines for setting and getting capabilities that is more comfortable and less likely to change than the interface provided by capset(2) and capget(2). This package also provides the setcap(8) and getcap(8) programs. It can be found at ⟨ http://www.kernel.org/pub/linux/libs/security/linux-privs ⟩.

Before kernel 2.6.24, and from kernel 2.6.24 to kernel 2.6.32 if file capabilities are not enabled, a thread with the CAP_SETPCAP capability can manipulate the capabilities of threads other than itself. However, this is only theoretically possible, since no thread ever has CAP_SETPCAP in either of these cases:

capsh(1), setpriv(1), prctl(2), setfsuid(2), cap_clear(3), cap__ext(3), cap_from_text(3), cap_get_file(3), cap_get_proc(3), cap_init(3), capgetp(3), capsetp(3), libcap(3), credentials(7), user_namespaces(7), pthreads(7), getcap(8), setcap(8)

include/linux/capability.h in the Linux kernel source tree

This page is part of release 4.04 of the Linux man-pages project. A description of the project, information about reporting bugs, and the latest version of this page, can be found at http://www.kernel.org/doc/man-pages/ .

Ⅳ linux nspr thread 和c的pthread庫有什麼區別

are/pthreads-win32/上可以查看pthread的相關介紹和信息，也可以下載pthread/pub/pthreads-win32/ 最新的dll，庫，頭文件和管理文檔 DLLs, LIBs, header files, and admin documentation ftp://sourceware.org/pub/pthreads-win32/dll-latest/

Ⅵ linux 進程的查看使用什麼命令

查看進程的命令有ps、pstree、pgrep等
1、ps
顯示進程信息，參數可省略
-aux 以BSD風格顯示進程
常用 -efH 以SystemV風格顯示進程
-e , -A 顯示所有進程
a 顯示終端上所有用戶的進程
x 顯示無終端進程
u顯示詳細信息
f 樹狀顯示
w 完整顯示信息
l 顯示長列表
各列輸出欄位的含義：
USER 進程所有者
PID 進程ID
PPID 父進程
%CPU CPU佔用率
%MEM 內存佔用率
NI 進程優先順序。數值越大，佔用CPU時間越少
VSZ 進程虛擬大小
RSS 頁面文件佔用
TTY 終端ID
STAT 進程狀態
+---D 不可中斷
Uninterruptible sleep (usually IO)
+---R 正在運行，或在隊列中的進程
+---S 處於休眠狀態
+---T 停止或被追蹤
+---Z 僵屍進程
+---W 進入內存交換（從內核2.6開始無效）
+---X 死掉的進程
+---< 高優先順序
+---N 低優先順序
+---L 有些頁被鎖進內存
+---s 包含子進程
+---+ 位於後台的進程組；
+---l 多線程，克隆線程 multi-threaded (using CLONE_THREAD, like
NPTL pthreads do)
PID:進程標識符，系統為每一個進程分配一個識別碼，稱為PID。
ps命令極為常用，其他命令還有：
2.pstree
樹狀顯示進程信息
-a 顯示完整命令及參數
-c 重復進程分別顯示
-c 顯示進程ID、PID
-n 按 PID排列進程
3.pgrep<進程名>
顯示進程的PID
-l 顯示進程名和進程PID
-o 進程起始ID
-n 進程終止ID

Ⅶ 如何在Linux中統計一個進程的線程數

三種方法：1。 使用top命令，具體用法是 top -H 加上這個選項，top的每一行就不是顯示一個進程，而是一個線程。
2。 使用ps命令，具體用法是 ps -xH 這樣可以查看所有存在的線程，也可以使用grep作進一步的過濾。3。 使用ps命令，具體用法是 ps -mq PID 這樣可以看到指定的進程產生的線程數目。更進一步，其實一些系統監控工具，在本質上也是讀取的系統產生的文件罷了。比如說進程這個事情，現在假設有進程號為 5000 的進程，查看這個進程的所有具體信息，在哪查看呢?看看這個目錄吧，/proc/5000/ 這裡面有你所有想要的。其實stat代表著當前的一些信息。使用ps命令來查看進程的時候，進程狀態分別對應的含義如下：D 不可中斷睡眠 (通常是在IO操作) 收到信號不喚醒和不可運行, 進程必須等待直到有中斷發生
R 正在運行或可運行（在運行隊列排隊中）
S 可中斷睡眠 (休眠中, 受阻, 在等待某個條件的形成或接受到信號)
T 已停止的 進程收到SIGSTOP, SIGSTP, SIGTIN, SIGTOU信號後停止運行
W 正在換頁(2.6.內核之前有效)
X 死進程 (未開啟)
Z 僵屍進程 進程已終止, 但進程描述符存在, 直到父進程調用wait4()系統調用後釋放BSD風格的
< 高優先順序(not nice to other users)
N 低優先順序(nice to other users)
L 頁面鎖定在內存（實時和定製的IO）
s 一個信息頭
l 多線程（使用 CLONE_THREAD，像NPTL的pthreads的那樣）+ 在前台進程組

Ⅷ linux qt 編譯時與運行時缺乏共享庫

LIBS += -L /usr/local/lib -levent -levent_core -levent_extra -levent_pthreads
/usr/local/lib 為lib庫所在路徑
-levent -levent_core -levent_extra -levent_pthreads為需要鏈接的庫

缺少動態連接庫.so--cannot open shared object file: No such file or directory

總結下來主要有3種方法：

ln -s /where/you/install/lib/*.so /usr/lib // -s選項不懂意思

sudo ldconfig //載入配置項? 用來刷新共享庫緩存 詳細請見: ldd和ldconfig命令2013-02-06

// 我是用第一種方法完成了修改 但是不太懂 sudo ldconfig 的意思 大概是載入配置項吧

export LD_LIBRARY_PATH=/where/you/install/lib:$LD_LIBRARY_PATH

sudo ldconfig

vim /etc/ld.so.conf

add /where/you/install/lib

sudo ldconfig

Ⅸ Linux下安裝mathgl時出現Please install posix threads headers怎麼辦

posix threads是posix標准庫中用於創建和管理線程的組件，又叫pthreads。在glibc標准庫中就包含有libpthread。所以，你需要安裝glibc，如果你已經安裝了glibc還是提示這個，那應該是沒有安裝glibc-headers（我印象里安裝glibc時會自動安裝glibc-headers的）

Ⅹ linux 下查看進程用什麼命令

linux 下查看進程可以使用的命令：

1、ps命令查找與進程相關的PID號：

2、ps a 顯示現行終端機下的所有程序，包括其他用戶的程序。

3、ps -A 顯示所有程序。

4、ps c 列出程序時，顯示每個程序真正的指令名稱，而不包含路徑，參數或常駐服務的標示。

5、ps -e 此參數的效果和指定"A"參數相同。

6、ps e 列出程序時，顯示每個程序所使用的環境變數。

7、ps f 用ASCII字元顯示樹狀結構，表達程序間的相互關系。

8、ps -H 顯示樹狀結構，表示程序間的相互關系。

9、ps -N 顯示所有的程序，除了執行ps指令終端機下的程序之外。

10、ps s 採用程序信號的格式顯示程序狀況。

11、ps S 列出程序時，包括已中斷的子程序資料。

12、ps -t<終端機編號> 指定終端機編號，並列出屬於該終端機的程序的狀況。

13、ps u 以用戶為主的格式來顯示程序狀況。

14、ps x 顯示所有程序，不以終端機來區分。