Sponsored Content
Top Forums UNIX for Advanced & Expert Users thread context switches: detection, prevention Post 302177746 by fabulous2 on Sunday 23rd of March 2008 05:44:49 AM
Old 03-23-2008
thread context switches: detection, prevention

#1: does anyone know how to detect how many times (and/or the time length) a given thread has been context switched out of the CPU?

#2: are there any tchniques that minimize/eliminate your thread getting context switched?

I would be happy to know the answers to these questions for ANY operating system, not only real ones like solaris and linux, but even (pinch your noise) Windows.

Here is the little bit that I currently know:

#1:
Apparently Solaris records context switch counts; see this discussion:
JMX - Any way to detect thread context switches?

Unfortunately, I too am running a Java program, and so the issue mentioned in that posting about how to figure out the mapping between your Java thread ID and solaris's LWP ID remains for me too.

Is there any functionality in Linux or Windows to what is described in that discussion?


#2:
Well, you can do obvious things, such as run no other programs, disable as many daemons/services as possible.

Is there any other configuration that you can do? I have tried setting my java program's thread priority to max in the hope this would prevent it, but it doesn't seem too.

Is there some version of linux that you can run in which you can muck with the thread scheduler and alter its policies to minimize hot threads from be switched out? (I have a dual core CPU, so if my app's main thread fully occupies one core, the other core is still free to run stuff from the operating system, so I see no reason why my hot thread needs to ever be swapped out--or am I missing something?).

Or maybe a real time OS in which you specify that a thread has to run for a certain length of time completely unmolested?
 

4 More Discussions You Might Find Interesting

1. Programming

Signal Handling and Context Switches

Hi guys, this is my first posting, so at first hi to everyone! ;) I have a problem with ucontext_t in connection with signal handling. I want to simulate a preemptive scheduler. I am using the iTimer with ITIMER_PROF, to schedule the interrupts. You find the code below: #include <stdio.h>... (18 Replies)
Discussion started by: XComp
18 Replies

2. Cybersecurity

Anyone knows any prevention against identity theft?

I have recently been victimized by the theft of my credit card. But, due to favorable situations I could prevent it from being miss-used and was able to make thins go in the right way.Anyways , I would like to know that if there any services which keeps your financial information safe and make you... (4 Replies)
Discussion started by: levi
4 Replies

3. Programming

Parallel Processing Detection and Program Return Value Detection

Hey, for the purpose of a research project I need to know if a specific type of parallel processing is being utilized by any user-run programs. Is there a way to detect whether a program either returns a value to another program at the end of execution, or just utilizes any form of parallel... (4 Replies)
Discussion started by: azar.zorn
4 Replies

4. Shell Programming and Scripting

Questions related to if in awk context and if without awk context

I wrote this code, questions follow #! /bin/bash -f # Purpose - to show how if syntax is used within an awk clear; ls -l; echo "This will print out the first two columns of the inputted file in this directory"; echo "Enter filename found in this directory"; read input; ... (11 Replies)
Discussion started by: Seth
11 Replies
MI_SWITCH(9)						   BSD Kernel Developer's Manual					      MI_SWITCH(9)

NAME
mi_switch, cpu_switch, cpu_throw -- switch to another thread context SYNOPSIS
#include <sys/param.h> #include <sys/proc.h> void mi_switch(void); void cpu_switch(void); void cpu_throw(void); DESCRIPTION
The mi_switch() function implements the machine independent prelude to a thread context switch. It is called from only a few distinguished places in the kernel code as a result of the principle of non-preemptable kernel mode execution. The various major uses of mi_switch can be enumerated as follows: 1. From within a function such as cv_wait(9), mtx_lock, or tsleep(9) when the current thread voluntarily relinquishes the CPU to wait for some resource or lock to become available. 2. After handling a trap (e.g. a system call, device interrupt) when the kernel prepares a return to user-mode execution. This case is typically handled by machine dependent trap-handling code after detection of a change in the signal disposition of the current process, or when a higher priority thread might be available to run. The latter event is communicated by the machine independent scheduling routines by calling the machine defined need_resched(). 3. In the signal handling code (see issignal(9)) if a signal is delivered that causes a process to stop. 4. When a thread dies in thread_exit(9) and control of the processor can be passed to the next runnable thread. 5. In thread_suspend_check(9) where a thread needs to stop execution due to the suspension state of the process as a whole. mi_switch() records the amount of time the current thread has been running in the process structures and checks this value against the CPU time limits allocated to the process (see getrlimit(2)). Exceeding the soft limit results in a SIGXCPU signal to be posted to the process, while exceeding the hard limit will cause a SIGKILL. If the thread is still in the TDS_RUNNING state, mi_switch() will put it back onto the run queue, assuming that it will want to run again soon. If it is in one of the other states and KSE threading is enabled, the associated KSE will be made available to any higher priority threads from the same group, to allow them to be scheduled next. After these administrative tasks are done, mi_switch() hands over control to the machine dependent routine cpu_switch(), which will perform the actual thread context switch. cpu_switch() first saves the context of the current thread. Next, it calls choosethread() to determine which thread to run next. Finally, it reads in the saved context of the new thread and starts to execute the new thread. cpu_throw() is similar to cpu_switch() except that it does not save the context of the old thread. This function is useful when the kernel does not have an old thread context to save, such as when CPUs other than the boot CPU perform their first task switch, or when the kernel does not care about the state of the old thread, such as in thread_exit() when the kernel terminates the current thread and switches into a new thread. To protect the runqueue(9), all of these functions must be called with the sched_lock mutex held. SEE ALSO
cv_wait(9), issignal(9), mutex(9), runqueue(9), tsleep(9), wakeup(9) BSD
November 24, 1996 BSD
All times are GMT -4. The time now is 07:14 PM.
Unix & Linux Forums Content Copyright 1993-2022. All Rights Reserved.
Privacy Policy