My understanding is that a non-maskable interrupt enforces context switching (which causes a process to be moved from CPU to ready queue). If the interrupt happens at a time when the process is executing its critical section, it may make the output indeterministic. One solution is to roll back to the state when the process entered the critical section, but I don't know if that is possible. Please help clarify this. Thanks in advance!
If there would be a way that roll back would happen, I honestly do not know.
Yes, there is ways of doing so by software of course, the developer could implement guards in his/her code to check if there is an anomaly if so they are will repeat the process again to avoid the corrupted data.
Related
I've been working on code to test the speed of the APIC using the PIT. There are several problems I can't figure out. First, when testing my ISRs for the two timers, I get general protection faults on the iretq instructions. Second, neither timer actually fires any interrupts. Any help on this would be much appreciated.
Link to the relevant file.
The general protection faults were caused by having an invalid CS register due to not reloading the CS register after loading the GDT. It's not in the code I linked to at all.
I've been doing some tests recently with an app switching between networks (Wi-fi, 3G, LTE, offline). I've been using Reachability when detecting this switches, but I'm not currently happy with the implementation when the app goes in an "offline state" for example.
I'm basically just throwing NSLogs currently when the no-network kicks in, but I've seen it go off in between switches. So my question... how do you best manage these things? Do you give it a delay in after no-network of a few seconds before going into "offline state"? Or are there other ways to improve this?
Big issue when streaming audio.. I wouldn't want to go into this offline state when is just a simple network switch or small connection loss. One of the things I would do is to wait for the buffer to be empty before changing states.
Yes, just check twice. Using your example, when you get the "offline" notification, you flip a flag (BOOL claimingOffline). Then when your buffer empties you check the status. If back online, you unflip the afore mentioned flag. If still offline, you flip the flag and go into "offline mode". This technique allows you to wait until the moment you really need to know (when the buffer empties). Otherwise you could use a timer, but it's suboptimal and not nearly as elegant...
I am trying to figure out how to use a background thread to execute a command ever 4hrs.
I have never created anything like this before so have only been reading about it so far.. One of the things I have read are this
"Threads tie up physical memory and critical system resources"
So in that case would it be a bad idead to have this thread that checkes the time then executes my method... or is there a better option, I have read about GCD (Grand Central Dispatch) but I am not sure if this is applicable as I think its more for concurrent requests? not something that repeats over and over again checking the time..
Or finally is there something I have completely missed where you can execute a request every 4hrs?
Any help would be greatly appreciated.
There is a max time background processes are allowed to run (10 min) which would make your approach difficult. Your next best attempt is to calculate the next event as save the times tamp somewhere. Then if the app is executed at or after that event it can carry out whatever action you want.
This might help:
http://www.audacious-software.com/2011/01/ios-background-processing-limits/
I think that it would be good to make use of a time stamp and post a notification for when the time reaches for hours from now.
Multithreading is not a good means to do this because essentially you would be running a loop for four hours eating clock cycles. Thanks to the magic of operating systems this would not eat up an entire core or anything silly like that however it would be continuously computed if it was allowed to run. This would be a vast waste of resources so it is not allowed. GCD was not really meant for this kind of thing. It was meant to allow for concurrency to smooth out UI interaction as well as complete tasks more efficiently, a 4hr loop would be inefficent. Think of concurrency as a tool for something like being able to interact with a table while its content is being loaded or changed. GCD blocks make this very easy when used correctly. GCD and other multithreading abilities give tools to do calculations in the background as well as interact with databases and deal with requests without ever affecting the users experience. Many people whom are much smarter then me have written exstensively on what multithreading/multitasking is and what it is good for. In a way posting a message for a time would be method of multitasking without the nastiness of constantly executing blocks through GCD to wait for the 4 hr time period, however it is possible to do this. You could execute a block that monitored for time less then the max length of a threads lifetime then when the threads execution is over dispatch it again until the desired time is achieved. This is a bad way of doing this. Post a notification to the notification center, its easy and will accomplish your goal without having to deal with the complexity of multithreading yourself.
You can post a notification request observing for a time change and it will return its note, however this requires you application be active or in the background. I can not guarantee the OS wont kill your application however if it is nice and quiet with a small memory footprint in "background" state its notification center request will remain active and function as intended.
We've got a requirement to determine whether the user is waiting on a program to do something. The biggest issue I see here is, if I monitor user activity (Keyboard and Mouse) then I'll assume the user is waiting when they might be reading, thinking, on the phone, etc.
Sometimes, if I know I'm going to have to wait a long time on a process (like booting up), I'll go get a coffee whilst it loads. I'm not really waiting on any one program, I'm just being efficient with my time.
I'm open to any ideas, even requesting the user use a key or key-combination to indicate they're waiting.
Is there a way to determine whether a user is waiting on a program?
Give the user the illusion that they could do the next step of interaction, i.e. don't tell them right away that the previous action has not completed. Then, when they try do something, you'll notice that they really would like to do something now and hence are waiting if they can't.
In some cases, you may find that what they want to do can actually be done right away, despite the previous action still being in progress.
You can't tell what a non-interacting user is doing. They could be day dreaming and you'd have no idea if they were waiting on the computer or not.
You might be able to deduce from user interaction that a user was waiting when you see no activity during a period of time when disk and or CPU usage is high. But this is not a scientific measure, it's merely an indicator. The assumption that the user was waiting negates the possibility to use the results for meaningful measurements.
I have an application that opens a connection with 2 sockets (in and out) and I want to have them working in a thread.
The reason that I want them to be in a separate thread is that I don't want my application to freeze when I receive data, and this can happen anytime as long as the application is running.
Currently I have a class that handle also network communication and I run this class in an NSOperation, I'm not sure if it's the best solution.
I'm not very familiar with threading so guys if you could give me some help I would be very grateful.
Thanks
First, you should know that you can use the same socket to send and receive data — they're generally bi-directional. You should be able to share a reference to the same socket among multiple threads of execution.
Second, unless you'll be receiving large amounts of data and have experienced performance issues with your UI, I would delay optimizing for it. (Don't get me wrong, this is a good consideration, but premature optimization is the root of all evil, and simpler is generally better if it performs adequately.)
Third, NSOperation objects are "single-shot", meaning that once the main method completes, the operation task cannot be used again. This may or may not be conducive to your networking model. You might also look at NSThread. The fact that you already have the functionality "factored out" bodes well for your design, whatever turns out to be best.
Lastly, threading is a complex topic, but a good place to start (especially for Objective-C) is Apple's Threading Programming Guide.