3

I know you can limit the uses of limited resources with semaphores, but how can I make it apply to the CPU (or the kernel, if that's a wise thing to do).

I have multiple threads running at the same time on a single processor. But on one of the threads I want to run a piece of code where I send a signal and I need to time how long it takes for the signal to gets back. The signals seem very distorted, whereas in the past these signals have been fine. I'm positive the hardware is working fine, so I believe that adding these extra threads have made the timing of the response pulse inaccurate. It's a very weak cpu. I'd like to try and block the cpu from doing anything but retrieving and timing the return pulse; that should be possible I believe.

Here's a quick rundown on what I'm trying to achieve:

-multiple threads are running
-on the thread with the pulse signaling a pulse has been sent
 --> stop cpu from processing other threads
 --> return pulse has been received
 --> cpu is now free to continue it's work

I will insert sleep() methods between pulses so the cpu doesn't become locked out for the other threads.

I know how the semaphore works, question is, how do I make it work on the cpu?

Babyburger
  • 1,730
  • 3
  • 19
  • 32
  • 1
    I believe that if this is CPython and these are Python threads, that only one thread can run at a time. That is because of Python's Global Interpretor Lock (GIL). C code you call is not governed by the GIL. Processes are a different matter. – octopusgrabbus Nov 20 '13 at 21:02
  • Yes, I'm using CPython. I should've clarified that more clearly... I only have a single processor, so I'm afraid multi processing is out of the question. I'm now thinking on using a job scheduler to simulate thread priority. This is what wikipedia has to say about what job scheduling functionality includes: 'priorities and/or queues to control the execution order of unrelated jobs'. This seems exactly what I'm looking for. So I'd raise the priority of a thread before running my block of code, then afterwards I level the priority back to normal. Is this a good way of reasoning? – Babyburger Nov 21 '13 at 12:31
  • My knowledge of threads is old and limited to Microsoft NT. Microsoft wanted to get people started programming with threads using their tools and technology back in the late 1990s, before the advent of multi-core boards. And, using threads did provide some useful effects in UIs. However, with some differences, I would think multi-threads and processes still have to be scheduled and take their turns respectively on one processor. And, you still need to think about the GIL. – octopusgrabbus Nov 21 '13 at 15:25
  • Here is a link to a description of the GIL. My point about threads running at once is contained early on. https://wiki.python.org/moin/GlobalInterpreterLock – octopusgrabbus Nov 21 '13 at 15:43

2 Answers2

1

CPython doesn't deal well with CPU-bound threads on multicore systems, unless you disable all but one of your cores in your OS.

Here's a presentation on the topic: https://www.youtube.com/watch?v=ph374fJqFPE

CPython does fine for I/O bound, multithreaded workloads, but even one CPU-bound thread makes a mess of that on multicore.

I recommend that you consider using multiprocessing instead of multithreading, unless you're purely I/O bound. That or use Jython or IronPython, which thread well.

dstromberg
  • 6,954
  • 1
  • 26
  • 27
1

The normal way to handle this sort of thing is to adjust the thread's priority. Unfortunately, you don't seem to be able to do that in Python. A previous question went into detail on why you can't do it. I'm not sure I buy the claim that the GIL would get in the way. I have not examined the implementation of the GIL, but one of the obvious ways to implement it is to use the native threading facility's low-level locking primitives (mutexes and the like). Typically these do respect threading priority. Unfortunately, that seems to be moot if you can't manipulate the priority.

Community
  • 1
  • 1
Sam Hartman
  • 6,210
  • 3
  • 23
  • 40
  • Sam Hartman: As I understand it, the GIL prevents multiple threads from running at once, even in a multi-processor environment. However, my understanding may be very incomplete. – octopusgrabbus Nov 21 '13 at 15:27
  • @octopusgrabus Yes, GIL prevents multi-processing from being used. Still we're talking about thread priority here. If the OS chooses which thread gets the GIL you could always guarantee the high-priority thread ran. There are issues related to other locks like priority inversion etc and deadlock avoidance. – Sam Hartman Nov 21 '13 at 17:16