4

I am using a proprietary C++ library on linux, compiled through gcc, which uses pthreads (I have to use the -lpthreads flag on gcc). I have a wrapper around it, and I know that the library is using multiple threads.

The library uses multiple threads dynamically - when I call it I can see anywhere between 20 an 1 threads. But I don't want to use taskset. (I have other processes running and I want the system to administer cores).

Is there a way to force my executable to use single thread? Either on compile or on run time. Thanks.

EDIT: I can run the executable with taskset, and then cat /proc//status gives me:

State: R (running) Tgid: 1623 Pid: 1623 PPid: 31002 TracerPid: 0 Uid: 500 500 500 500 Gid: 100 100 100 100 Utrace: 0 FDSize: 256 Groups: 100 VmPeak: 346528 kB VmSize: 345956 kB VmLck: 0 kB VmHWM: 199816 kB VmRSS: 188388 kB VmData: 192120 kB VmStk: 128 kB VmExe: 656 kB VmLib: 12444 kB VmPTE: 432 kB VmSwap: 0 kB Threads: 1 SigQ: 2/62004 SigPnd: 0000000000000000 ShdPnd: 0000000000000000 SigBlk: 0000000000000000 SigIgn: 0000000000000004 SigCgt: 0000000180000000 CapInh: 0000000000000000 CapPrm: 0000000000000000 CapEff: 0000000000000000 CapBnd: ffffffffffffffff Cpus_allowed: 02 Cpus_allowed_list: 1 Mems_allowed: 00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000001 Mems_allowed_list: 0 voluntary_ctxt_switches: 3460 nonvoluntary_ctxt_switches: 24907

So, apparently, it can run single thread.

mousomer
  • 2,632
  • 2
  • 24
  • 25
  • 2
    You are aware that the library will possibly/probably not work anymore if you only allow 1 thread? Do you perhaps mean to restrict execution of your executable to a single core? – Simon Kraemer Jan 20 '16 at 09:20
  • I need to test the possibility. It might not work, I know. The executable uses the lib, so I don't understand what you mean by "restricting the executable and not the lib". When I run the executable, it calls multi thread functions from the lib. – mousomer Jan 20 '16 at 09:26
  • 1
    Yes and the library relies on these threads. Let's say the library handles 2 message queues in 2 different threads. If you now eliminate the multithreading : Which thread/message queue is allowed to run? What about the other one? There is probably a reason why the library uses pthreads. – Simon Kraemer Jan 20 '16 at 09:30
  • You said, you have a wrapper around it and to force my executable to use single thread? Can you elaborate it more clarity!! – Dhananjay Kashyap Jan 20 '16 at 09:31
  • 3
    It's really not clear what you're asking. If something use multiple threads, it won't work with a single thread ; it was designed that way. If it is already using only 1 thread, then what is the problem ? Maybe you are confusing threads and cores ? Multi-thread can be single-core. – ElderBug Jan 20 '16 at 09:49
  • 1
    I'm voting to close this question as off-topic because it appears to be the result of a misunderstanding what a thread is. – MSalters Jan 20 '16 at 10:53
  • This seems like an XY problem. You should ask about the problem you're trying to solve not how you think you should it. Nowhere do you explain what problem you're trying to solve by forcing a library to use a single thread, making it impossible for us to give you useful answers. We can't help you solve a problem without knowing what problem you're trying to solve. Just knowing what you think will solve it is not good enough. It's like going to a doctor and asking "how can I get some drugs to take?" He has to know whether you're sick, and so on. – David Schwartz Jan 21 '16 at 07:26

3 Answers3

5

If you don't care about spawning threads and just want the program to behave sequentially, you can use numactl on linux.

Taken from this answer on SuperUser, you can restrict the program to executing one thread at a time by using

numactl --physcpubind=+1 /path/to/your/executable

From the numactl documentation:

--physcpubind=cpus, -C cpus

Only execute process on cpus. This accepts cpu numbers as shown in the processor fields of /proc/cpuinfo, or relative cpus as in relative to the current cpuset.

The program will still spawn threads, but is restricted to executing on a single CPU. This means only one thread can run at a time.

Increasingly Idiotic
  • 5,700
  • 5
  • 35
  • 73
1

Without knowing what you are trying to do, there is only one answer : You can't.

How would you restrain something to not use multiple threads ? Disabling pthread_create() would only cripple the program. Imagine that the lib spawns a thread to do some async work on a file. If you forbid pthread_create(), what happens to the file operations ? The lib now doesn't work properly, since it can't do its file operations. You would need a complete redesign of the lib ; just smashing the file IO on the same thread (if it was even possible) would probably be disastrous, since this thread was supposed to be free running, and now is blocked by some heavy IO.

That's the general idea. Regardless of whether the threads are really needed, if a lib was designed to be multi-thread, you can't simply make it single-thread. You can however use taskset, as you mentioned, or sched_setaffinity() (from C/C++) to run a process on a single CORE.

ElderBug
  • 5,926
  • 16
  • 25
  • Well, taskset works. When I run with taskset, the lib does not generate multiple threads, and it actually runs 70% faster. I'm still not sure of taskset is exactly what I was looking for. – mousomer Jan 20 '16 at 11:50
  • @mousomer It is of course possible that the library is badly designed, but I find it strange that it would have a different behavior after `taskset`. Maybe the lib is counting the number of cores, but then I'm not sure that `taskset` would influence the number that the lib reads. Did you check if the lib has an option to somewhat control the threading ? – ElderBug Jan 20 '16 at 12:27
  • I checked, and it does not have a thread controller. It seems as if the lib has runaway threads which hamper runtime. With taskset I get 600ms per data file, but 2.5 sec per file without it. Problem is, the server is running other things. Won't it be problematic to use taskset? Won't it interfere with other processes? – mousomer Jan 20 '16 at 13:09
  • 1
    @mousomer It really depends on what you want to achieve and how you do it. If you use a lot of taskset for the same core, obviously it won't be good. About the lib, if its job is to process files asynchronously, maybe the slow down is just because of disk access. If it is the case, you should wait that a file is finished before processing the next (to be honest, the lib should be the one doing that). – ElderBug Jan 20 '16 at 13:24
0

Dont know much about the internals of the process. But why dont you enhance your code base to restrict creating more than 1 thread. You can maintain a count of the threads and stop creating threads in the process when the count reaches more than 1.

Vijay
  • 65,327
  • 90
  • 227
  • 319