[C#] Which System.Threading class to use?

I'm still confused by your arguments ;) You seem to be suggesting that you shouldn't write a threadsafe queue implementation, even when you know how it is to be used :p
 
Ok, well to start, things are never written to the file in batch - so that's a non-issue (for the foreseeable anyway).

To answer the question of "How can I be sure all messages are being sent" it's because we have a parsing application that flags alerts when things are missed out on. :)

And that's using the old version (not even that of what I've made in this thread) :)

My next question, and I'm being too lazy to just test it, can a thread that has finished execution (normally, not Abort() or exception) be Start()ed?
 
Last edited:
Dj_Jestar said:
As for the StreamWriter.. it's handle would be closed after exiting the method, surely? Or are you telling me the garbage collection is that poor in .NET?
Click to expand...

The streamwriter handles unmanaged resources which are out of scope of the gc, hence it should be closed explicitly.
 
An object going out of scope does not result in it immediately being garbage collected.

Your program would have to wait, potentially a very very long time, for the next garbage collection in order for the StreamWriter to be freed. Until that time the file would be locked.

Dispose() is there so you can explicitly release the object. I would recommend using a using {} block though.
 
So an object does not get garbage collected when it's reference counter reaches <1 ? :/

OK, I'll add Dispose(); or Close(); to the method when it's finished.
 
Dj_Jestar said:
So an object does not get garbage collected when it's reference counter reaches <1 ? :/

OK, I'll add Dispose(); or Close(); to the method when it's finished.
Click to expand...

Objects don't have reference counters in the CLR; it would be far too costly.

The CLR's GC determines which objects are permanently out of scope by testing each object for reachability – i.e. whether it can be reached from a root object (e.g. an object referenced by a static field). The JVM's GC works in much the same way I believe.
 
Last edited:
Inquisitor said:
Objects don't have reference counters in the CLR; keeping track of how many references each object has would incur a huge performance hit.

The CLR's GC determines which objects are permanently out of scope by testing each object for reachability – i.e. whether it can be reached from a root object (e.g. an object referenced by a static field). The JVM's GC works in much the same way I believe.
Click to expand...

Indeed the JVM does. Generational garbage collector - kinda mark and sweep but better. The unpredictability of the garbage collector is one reason why specific JVM have had to be built for real time systems .. because you can't afford to have blackouts when the GC kicks in unexpectedly.
 
Last edited:
Dj_Jestar said:
So an object does not get garbage collected when it's reference counter reaches <1 ? :/
Click to expand...

Correct. Think of "going out of scope" like putting your dust bin out for collection. But just because you've put it out doesn't stop the actual dust men and their truck arriving until the next day at some point when they feel like doing your street...
 
Smalltalk manages it without loss of performance. So I don't see why CLR can't. But nevermind, this will only end in an evangelical war.

Thanks for the info.
 
Dj_Jestar said:
Smalltalk manages it without loss of performance. So I don't see why CLR can't. But nevermind, this will only end in an evangelical war.

Thanks for the info.
Click to expand...

Perhaps if you have a time machine :p GNU smalltalk vm these days uses generation, mark & sweep and compaction like the JVM/CLR.
 
Last edited:
You must log in or register to reply here.
Back
Top Bottom