This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

[DM8148]: Thread number for Capture/Encode

Hello TI,


I've been doing some performance measurements on my application which is a customized Capture/Encode demo. It uses Capture/DEI/Encode components, OpenGL texturing (GPU Composition) and live streaming over RTP.

When executing a simple cat /proc/app_PID/status, I noticed that the application has 14 created threads. I am aware that with VFCC, VENC and DEI components, at least 4 threads are created (IL_ClientOutputBitStreamWriteTask()x1 and IL_ClientConnInConnOutTask() x3) but I just can't figure out why there are 14 threads running.

The Capture/Encode demo without any modifications creates 11 threads. This seems very high knowing that the A8 is just a single core processor running at 1GHz, I just don't understand very well how an application can run 11 threads and how this CPU can handle it.

Do you have any idea where this huge quantity of threads come from ?

Screenshot of /proc/status of the original capture/encode demo:

cat /proc/1385/status
Name:   capture_encode_
State:  S (sleeping)
Tgid:   1385
Pid:    1385
PPid:   1381
TracerPid:      0
Uid:    0       0       0       0
Gid:    0       0       0       0
FDSize: 256
Groups: 0
VmPeak:   441324 kB
VmSize:    27644 kB
VmLck:         0 kB
VmHWM:      1552 kB
VmRSS:      1552 kB
VmData:    25116 kB
VmStk:       136 kB
VmExe:       800 kB
VmLib:      1408 kB
VmPTE:       438 kB
VmSwap:        0 kB
Threads:        11
SigQ:   0/950
SigPnd: 0000000000000000
ShdPnd: 0000000000000000
SigBlk: 0000000000000000
SigIgn: 0000000000000000
SigCgt: 0000000180000002
CapInh: 0000000000000000
CapPrm: ffffffffffffffff
CapEff: ffffffffffffffff
CapBnd: ffffffffffffffff
Cpus_allowed:   1
Cpus_allowed_list:      0
voluntary_ctxt_switches:        212
nonvoluntary_ctxt_switches:     63

Thank you very much for your help.

Dylan

  • DOMX the framework for supporting RPC of OMX APIs will create one thread per component and one thread per core.

    These threads are always in blocked state and activate when invoking an OMX API. It is still not clear how 14 threads apprear.

    Can you monitor /proc/<pid>/stat after OMX_init of your app (You should see +2 threads ) and after doing OMX_GetHandle (You should see +1 thread) for each component.

    Below function can be used as reference if you want to get thread count programmatically at different points in execution

    #include <stdint.h>
    #include <limits.h>
    #include <dirent.h>
    #include <sys/types.h>
    #include <unistd.h>
    
    Int32 OSA_GetThreadCount()
    {
        Int32 file_count = 0;
        DIR * dirp;
        struct dirent * entry;
        pid_t cur_pid;
        char thread_count_path[1024];
    
        cur_pid = getpid();
        printf("\nOSA: Getting thread count for process:%d\n",cur_pid);
        snprintf(thread_count_path,sizeof(thread_count_path) - 1,"/proc/%d/task",cur_pid);
        thread_count_path[sizeof(thread_count_path) - 1] = 0;
    
        printf("\nOSA: Thread Count paths:%s\n",thread_count_path);
        dirp = opendir(thread_count_path); /* There should be error handling after this */
        if (dirp == NULL)
            return -1;
        while ((entry = readdir(dirp)) != NULL) {
            file_count++;
        }
        closedir(dirp);
        printf("\nOSA: Thread Count :%d\n",file_count);
        return file_count;
    }