Hello guys i have question
When a process is entering the critical region one way to stop other processes to enter the same critical region is to disable the interupts
My problem is:
Ok we disable the interrupts so the hardware can no longer stop this procces but if the sceduler says "ok i am stopping you so i can run another procces" and this new process enters the same critical region then we have a problem because this procces is going to enter the same critical region.What happens when this happens?
Thank you!
Related
When looking at Process monitor from Microsoft Technet, I see the TCP send Receive and Copy.
I notice that the Copy appears to be a replication of a transmission, but dont understand why it happens sometimes and not others.
Screen shot of TCPCopy issue
I believe "TCPCopy" event indicates that the received TCP packet is cloned/mirrored by another program (typically antivirus). From your screenshot, it looks like there's an antivirus scanning Outlook (POP/SMTP/IMAP) and Firefox (HTTP/S) packets. Can you try disabling mail and web traffic scanning (or realtime scanning) in your antivirus, and check if you still notice TCPCopy events in Process Monitor?
I've recently started at a new business and some of the processes are becoming a bit of a challenge to map out. Quite frequently we have a process that needs to go "on hold" when an event, which can occur at any point, is triggered. The problem I'm having mapping this out correctly is how to "restart" the process from where it left off, since it can effectively pause/unpause at any point.
Here's what I currently have:
Process Example
Basically, I need to have "Something Happened 2" not fully interrupt the sub-process, it just needs to put it on "hold". The actual situation is essentially that a customer can make a complaint while we handle their overdue bill, so we put the process on hold wherever it was at until we resolve the complaint, and then restart the process.
I'm not entirely sure the best approach to documenting this and couldn't find anything clear in the documentation, since a non-interupting event seems to have the rest of the process still continue forward in parallel.
Any help would be majorly appreciated.
If you really want to restart the whole sub-process from the beginning, then you could frontload an exclusive gateway. Once the complaint is dealt with, you can direct the sequence flow to that gateway, which would restart the sub-process. See below for an example (I have simplified your diagram a bit).
I am having trouble running the debugger on a STM32F205ZG using µVision4 and the ULINK2. I keep getting the error message "Could not stop Cortex-M device! Please check the JTAG cable." I am using the SW port. Any help with this would be greatly appreciated.
In my own experience I have usually seen this error when either the ULINK2 is disconnected and reconnected while in the middle of a debug session or if you have some external hardware, outside of the control of the debugger, that is acting on your processor.
If the ULINK2 was disconnected mid-debug, then usually cycling power to your device will fix the problem.
If you have something like a watchdog timer that is trying to reset the processor while you are in the middle of debugging, then you will have to disable the watchdog before you can start a debug session.
I've seen the same problem with my NXP uC.
The problem was that the code loaded in flash was faulty and was placing the CPU into a busy loop branching back to the same address, this prevented the debugger accessing the bus.
the uLink worked if I put the device into ISP mode as it never got to the user code.
it seems that uLink takes too long to halt the device after reset, the spec tells you this somewhere, so by the time uLink tries to halt the CPU it is too late as it cannot access the bus and locks up.
I had this problem on LPC4337. I tried all the solutions people are talking about but the only one that worked for me was using a lower processor clock so that JTAG/SWD interface can match/catch up with the processor before it is gone too far into executing user code. In my case I set JTAG/SWD clock in Keil uVision 5 to 10MHz and the changes the processor clock divisors to give 36MHz. With these settings, it never missed to capture on reset when I begin a debug session.
This happens for ULink2 but ULINK Pro and ULINK Pro-D support a JTAG/SWD <= 50MHz. See this link for more comparisons:
ulink comparisons
Just an other issue with this message:
We have the same error message, but the problem was the wrong state of the RESET line.
I am developping an objective c application and I would like to detect non responsives windows even if they are not own by my application.
Is there a way to be notified when a such case occurs?
Thanks in advance for your help,
Regards,
I think the only way to detect whether an window is hanging is to detect when its application is hanging. And I think the only way to - reliably - do this is to talk to it. Send it some inter-process message and await an action. I think that's exactly how the system detects it: there is some delay before the beach ball appears. And this is because the system sent a message and received no answer in x seconds.
What kind of message that might be is hard to say. Must be something that goes through the main event loop but can be sent by every application. I'm sure Google will be of some help finding it. I'm no pro in inter-process communications and would have to search as well.
You can use the Instruments application with a "Spin Monitor" instrument track. If you set it to monitor "All Processes", it will capture stack traces whenever an application hangs (doesn't process the main event loop for a long time).
I have a rather unusual problem. I am using xpdfprint binary for the print job from my application. But if the user has a "directly print to the printer" setting enabled and by mistake if the printer is not available (power failure or cord not plugged in) then the application hangs. It seems to be a standard behaviour since in my machine other windows applications also behave the same way. Problem is, in this case the printer timeout is not happening, neither it returns an error. It is waiting on the synchronous call to finish the printing. Is there anyway I can handle this situation? I am forced to find a solution because of a demanding customer. If by some means I get the physical printer status before the printing job is sent, I could solve this problem to an extent. Mine is a windows application and the coding is largely done in C#. If anybody has a win32 sample code please share with me.
Thanks in advance for any kind of help.
If the printer isn't connected then don't have a print menu item enabled, with a message.
Then, you just check every so often on the status.
You may find this of interest to check the status:
http://www.codeproject.com/KB/printing/printeroffline.aspx