I know there's nothing in the box ... but does anyone have any tricks.
Managed threads not OS threads please.
Cheers
Answering the comments:
Version is .Net 3.5.
I want all managed threads in the current running process.
I want them so I can get the call stack of everythread.
Thanks
I suspect that anything at this level would be done with the debugging hooks outside of managed code. By design, it isn't really geared up to let you do that. Of course, you could just use any existing debugger, etc (even just windbg/sos).
For you own threads - simply store away a reference when you create them. But of course, don't do this as a mechanism to abort them etc - there are much better (i.e. workable) ways of doing that with things like Monitor, Mutex, etc.
Of course, if you don't mind stepping outside of managed code I'm sure there are options...
Related
This question has been bugging me for a while: I've read in MSDN's DirectX article the following:
The destructor (of the application) should release any (Direct2D) interfaces stored...
DemoApp::~DemoApp()
{
SafeRelease(&m_pDirect2dFactory);
SafeRelease(&m_pRenderTarget);
SafeRelease(&m_pLightSlateGrayBrush);
SafeRelease(&m_pCornflowerBlueBrush);
}
Now, if all of the application's data is getting released/deallocated at the termination (source) why would I go through the trouble to make a function in-order-to/and release them individually? it makes no sense!
I keep seeing this more and more over the time, and it's obviously really bugging me.
The MSDN article above is the first time I've encountered this, so it made sense to mention it of all other cases.
Well, since so far I didn't actually ask my questions, here they are:
Do I need to release something before termination? (do explain why please)
Why did the author in MSDN haven chosen to do that?
Does the answer differ from native & managed code? I.E. Do I need to make sure everything's disposed at the end of the program while I'm writing a C# program? (I don't know about Java but if disposal exists there I'm sure other members would appreciate an answer for that too).
Thank you!
You don't need to worry about managed content when your application is terminating. When the entire process's memory is torn down all of that goes with it.
What matters is unmanaged resources.
If you have a lock on a file and the managed wrapper for the file handler is taken down when the application closes without you ever releasing the lock, you've now thrown away the only key that would allow access to the file.
If you have an internal buffer (say for logging errors) you may want to flush it before the application terminates. Not doing so would potentially mean the fatal error that caused the application to end isn't logged. That could be...bad.
If you have network connections open you'll want to close them. If you don't then the OS likely won't do it for you (at least not for a while; eventually it might notice the inactivity) and that's rather rude to whoever's on the other end. They may be continuing to listen for a response, or continuing to send you information, not knowing that you're not there anymore.
Now, if all of the application's data is getting released/deallocated
at the termination (source) why would I go through the trouble to make
a function in-order-to/and release them individually?
A number of reasons. One immediate reason is because not all resources are memory. Only memory gets reclaimed at process termination. If some of your resources are things like shared mutexes or file handles, not releasing those resources could mess up other programs or subsequent runs of your program.
I think there's a more important, more fundamental reason though. Not cleaning up after yourself is just lazy, sloppy programming. If you are lazy and sloppy in cleanup at termination, are you lazy and sloppy at other times? If your tendancy is to be lazy and sloppy and only override that tendancy in specific areas where you're cognizant of potential problems, then your tendancy is to be lazy and sloppy. What if there are potential problems you're not cognizant of? How can you rely on your overall philosophy of lazy, sloppy programming to write correct, robust programs?
Don't be that guy. Clean up after yourself.
I wrote a library on top of System.Data.SQLite and realized it (my library) has unpredictable behaviour when using Parallel.ForEach. I might debug this eventually (i.e. if I get/take the time), most likely by locking the right parts, but for now let's say I want to just prevent usage of Parallel.ForEach, or force usage of my library to allow (or result in) only a single thread, how would I proceed?
You can't control how your API is consumed by external code. If it's something you absolutely cannot address prior to release, it would be a good idea to be very explicit about failure cases in your documentation (both XML comments and any sort of "help file").
A few quick threadstatic attributes might solve your concurrency problem, but this smells like the tip of a much larger iceberg. Fix the root cause, not the symptom.
How can we use GC.KeepAlive() and what is the purpose?
I transfer files from terminal (Windows-CE) to Server using Socket. The time needed for transfer is 8 minutes. After 5 minutes the Windows-CE shuts down (if touch screen not pressed)
If I use GC.KeepAlive() for this, does this solve my problem?
You very rarely need to use GC.KeepAlive - very rarely. You'd use it if you wanted to prevent the side-effect of a finalizer from occurring too early, for example. I've most often seen it used for Mutex - keeping mutex alive until the end of an app to make sure there's only one instance. (A using statement is actually better here, but that's a separate matter.)
And no, it doesn't sound like it's relevant in your situation.
From the MSDN library for .NET:
The purpose of the KeepAlive method is to ensure the existence of a
reference to an object that is at risk of being prematurely reclaimed
by the garbage collector. A common scenario where this might happen is
when there are no references to the object in managed code or data,
but the object is still in use in unmanaged code such as Win32 APIs,
unmanaged DLLs, or methods using COM.
So not this would not solve your problem. In fact it's not even related to your problem.
The only thing you can do is in the service/application running on the Windows CE, adding code that prevents the system to shutdown as long as the transfer is in progress
The screen powering down is a power-management setting on the device. It's going to happen whether or not any app is running. The GC has absolutely nothing to do with this.
If you want to prevent the power maanger from putting hte device into a low-power state, you have a few options. You can periodically call SystemIdleTimerReset in your app.
You could force the power state to something you like with SetSystemPowerState.
You could change the power manager timeouts to something more to your liking by adjusting settings at [HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\Power\Timeouts] (followed by a WM_SETTINGS_CHANGE broadcast IIRC).
The best "solution" is going to depend on your app requirements, your users' requirements and the power management system of the target device.
I have the following card and cannot get interupts working. I may not be understanding how they're supposed to work correctly... I don't do this type of programming very often.
From the looks of it though, it should be able to generate an interrupt when something comes in on one of the IO ports, right? We've got it hooked up to a bunch of switches for machine operation.
http://accesio.com/go.cgi?p=../pci/pci_dio_24d.html
I'll post some of the code I'm working with as soon as I can. I'm trying to write something to the base address (which I have) + 0xE but that doesn't help... the AIOWDM WaitForIRQ method just returns with a 0 every time I call it... nothing happens.
Any help would be appreciated... I know this is kind of a generic question.
UPDATE: Even the sample application they provide doesn't detect any interrupts, and I know I have the jumpers installed correctly, so I'm guessing it doesn't just fire interrupts for everything... I'm guessing I have to wire each switch up to a certain IO pin too and that one pin is responsible for the interrupts...
In short, C# is not an appropriate language for this kind of task, as this is low-level unmanaged code. You could theoretically do it, but it would be more painful as you have to make frequent trips to the unmanaged world to deal with interrupts. I would advise to look at this from the likes of C/C++ native code which would perform better and handle this kind of low-level stuff.
Another reason why, since C# has their own garbage collection, the last thing you would want is for the interrupt handling mechanism to be disposed of in the garbage collection a la good bye to the precious data structure used for interrupt handling, this will add considerable overhead to the code in this regard.
Personally, I have never heard of C# dealing with this kind of thing, but some of the more astute readers will say, "hang on, what about the new fangled OS called Singularity, which is written in C#?", at the end of the day, using the .NET runtime to manage this hardware task is a no-no.
Edit:
After I realized, from looking at the reference manual, on one of the C code samples it is using outp, then I latched on the idea that you need to do direct port input output, I thought this might help, it is a dll that will enable you to do exactly that, input output, you would need to find the appropriate p/invoke signature to do this. There is another DLL that can do the same thing here. Also, check this WinRing0 code.
Again, you need to dig around and find the appropriate method signature suitable for pinvoking...
Best of luck with this..feel free to post any more and I'll try help out... :)
Hope this helps,
Best regards,
Tom.
I'm currently writing a library that can be used to show the internal state of some running code (mainly fields and properties both public and private). Objects are accessed in a different thread to put their info into a window for the user to see. The problem is, there are times while I'm walking a long IList in which its structure may change. Some piece of code in the program being 'watched' may add a new item, or even worse, remove some. This of course causes the whole thing to crash.
I've come up with some ideas but I'm afraid they're not quite correct:
Locking the list being accessed while I'm walking it. I'm not sure if this would work since the IList being used may have not been locked for writing at the other side.
Let the code being watched to be aware of my existence and provide some interfaces to allow for synchronization. (I'd really like it to be totally transparent though).
As a last resort, put every read access into a try/catch block and pretend as if nothing happened when it throws. (Can't think of an uglier solution that actually works).
Thanks in advance.
The only way you're going to keep things "transparent" to the code being monitored is to make the monitoring code robust in the face of state changes.
Some suggestions
Don't walk a shared list - make a copy of the list into a local List instance as soon (and as fast) as you can. Once you have a local (non-shared) list of instances, noone can monkey with the list.
Make things as robust as you can - putting every read into a try/catch might feel nasty, but you'll probably need to do it.
Option number 3 may feel ugly, but this looks to be similar to the approach the Visual Studio watch windows use, and I would choose that approach.
In Visual Studio, you can often set a watch on some list or collection and at a later point notice the watch simply displays an exception when it can't evaluate a certain value due to user or code state changes.
This is the most robust approach when dealing with such an open ended range of possibilities. The fact is, if your watching code is designed to support as many scenarios as possible you will not be able to think of all situations in advance. Handling and presenting exceptions nicely is the next best approach.
By the way, someone else mentioned that locking your data structures will work. This is not true if the "other code" is not also using locks for synchronization. In fact both pieces of code must lock the same synchronization object, very unlikely if you don't control the other code. (I think you mention this in your question, so I agree.)
While I like Bevan's idea of copying the list for local read access, if the list is particularly large, that may not be a truly viable option.
If you really need seamless, transparent, concurrent access to these lists, you should look into the Parallel Extensions for .NET library. It is currently available for .NET 2.0 through 3.5 as a CTP. The extensions will be officially included in .NET 4.0 along with some additional collections. I think you would be interested in the BlockingCollection from the CTP, which would give you that transparent concurrent access you need. There is obviously a performance hit as with any threaded stuff that involves synchronization, however these collections are fairly well optimized.
As I understand, you don't want to have ANY dependency/requirement on the code being watched or enforce any constrains on how the code is written.
Although this is my favourite approach to code a "watcher", this causes you application to face a very broad range of code and behaviours, which can cause it to crash.
So, as said before me, my advice is to make the watcher "robust" in the first step. You should be prepared for anything going wrong anywhere in your code, because considering the "transparency", many things can potentially go wrong! (Be careful where to put your try/catch, entering and leaving the try block many times can have a visible performance impact)
When you're done making your code robust, next steps would be making it more usable and dodging the situations that can cause exceptions, like the "list" thing you mentioned. For example, you can check the watched object and see if it's a list, and it's not too long, first make a quick copy of it and then do the rest. This way you eliminate a large amount of the probability that can make your code throw.
Locking the list will work, because it is being modified, as you've observed via the crashing :)
Seems to me, though, that I'd avoid locking (because it seems that your thread is only the 'watcher' and shouldn't really interrupt).
On this basis, I would just try and handle the cases where you determine missing things. Is this not possible?