1

I would like to know how to catch a thread being interrupted by a Context Switch in java. I got two threads running side by side, which are both changing the same int up and down, and I would like for the sake of my report, to know how to catch the switches, and do something. (eg. make a simple System.out when that happens) Thanks!

Martin
  • 157
  • 1
  • 11
  • I have found a solution to my own problem. :) It's not the most pretty one, but it seems to be working as far as I can see. I made it so the threads do a big calculation, and check first, if the last number generated through that calculation was equal the right result, because if it was interrupted in the middle of everything, then the result wouldn't be correct. If it isn't the correct one, it then reports that it was interrupted. :) – Martin Dec 07 '11 at 18:59
  • If a context switch gives you the wrong value, then you're doing something else wrong. Use local variables or synchronize or something. – Erick Robertson Dec 07 '11 at 19:02
  • You are aware that I'm actually TRYING to get a problem, right? :) As I WANT it to interrupt and give me the wrong result, so I can show that it switched. :) – Martin Dec 07 '11 at 19:04
  • No, I don't understand what you're trying to do at all. It makes no sense to me why it would be important, or why you would need this for your report. – Erick Robertson Dec 07 '11 at 19:07
  • I wanted this, because as I'm talking about the importance of using locks, or other kind of security, when working in the Critical Section, it's common sense to also talk about what happens if you don't. :) – Martin Dec 07 '11 at 19:09
  • no you are doing something wrong. the os handles saving and restoring your state when you context switch -- your calculation will produce exactly the same result regardless of whether you context switch or not. think about how many programs would break if what you are saying was true. only way i know of to do what you want is to modify the kernel. – Jesse Cohen Dec 08 '11 at 03:55

3 Answers3

3

As far as an application is concerned context switches are invisible - there is no signal or message sent to the application that notifies it.

The only thing that might tip off an application is timing. For example, if you time a tight loop repeatedly, you might be able to (unreliably) detect a context switch that happens as the loop is executed, due to the longer time required in comparison to executions that were not interrupted. Unfortunately, this would only be possible for compiled languages like C. Languages like Java that make use of a virtual machine make it practically impossible to reliably detect something like this because a loop slowing down might be attributed to any number of reasons, like e.g. the garbage collector acting up.

Moreover, keep in mind that any system call - and especially I/O calls like the ones you'd use to log such an event - very often cause an implicit context switch, which could throw off anything you might want to do.

Why would you want to know something like this anyway? And especially from a Java application?

EDIT:

Well, if you are after creating a synchronization problem, here's my version:

public class Test {
    public static long count = 0;

    public static void main(String[] args) {
        for (int run = 0; run < 5; ++run) {
            Test.count = 0;

            Thread[] threads = new Thread[10];

            for (int i = 0; i < threads.length; ++i) {
                threads[i] = new Thread(new Runnable() {
                    public void run() {
                        for (long i = 0; i < (10 * 1000 * 1000 * 1000); ++i) {
                            Test.count += 1;
                        }
                    }
                });
            }

            for (int i = 0; i < threads.length; ++i) {
                threads[i].start();
            }

            for (int i = 0; i < threads.length; ++i) {
                try {
                    threads[i].join();
                } catch (InterruptedException e) {
                    e.printStackTrace();
                }
            }

            System.out.println(Test.count);
        }
    }
}

Here's what I got from a single run:

1443685504
1439908180
1461384255
1477413204
1440892041
thkala
  • 84,049
  • 23
  • 157
  • 201
  • Thanks for the response! Sad to hear that it's just about impossible. I'm writing about Threads, locks and synchronization, and so I thought it would be great to show what happens if you stop locking every time you touch anything in the Critical Section. The reason it's in Java.. Well.. We haven't learned anything else. :) – Martin Dec 07 '11 at 18:38
  • @Martin: a broken implementation though... I'll update in a few minutes - too many bugs to weed out. – thkala Dec 07 '11 at 19:26
  • 1
    @Martin: OK, this version actually does the right thing in, uh, demonstrating the wrong thing to do... – thkala Dec 07 '11 at 19:33
2

Record the thread making the modification.

Every time the int is modified, store the thread that makes the modification. When it differs from the previous thread, make your System.out.

Otherwise, you would need an operating system that allows you to interrupt a context switch. I don't know of an operating system that allows you to do that.

Erick Robertson
  • 32,125
  • 13
  • 69
  • 98
  • 1. That would only detect context switches between threads of the same process - not context switches in general. 2. This would break *completely* if more than one processors are in use. – thkala Dec 07 '11 at 18:41
  • If the OP wants to put together a report on how often different threads modify the int, this is better than nothing. It won't break at all with proper synchronization. – Erick Robertson Dec 07 '11 at 18:45
  • 1
    I wonder if the OP is slightly confused about the meaning of the term "context switch". Context switches have little to do with the way a shared variable is mangled when accessed by multiple threads without locking... – thkala Dec 07 '11 at 18:50
  • @thkala That has nothing to do with what I was actually after. :) I wasn't after anything related to changing the variable. – Martin Dec 07 '11 at 19:00
0

I don't think you can listen events from thread scheduler (part ot OS Core) but you can use pull strategy:

  1. Make some static volatile string field
    • In every thread read this field(very often)
    • If field value != "current-thread-name" => print "Context is Switched to "+thread-name
    • write thread name to field
korifey
  • 3,379
  • 17
  • 17