well ive been a fan of Verdana for months now, in code and everywhere else. serifs are ugly and fixed width i find is too distracting. 9pt works for my code, on a black background with lots of vibrant neon-colour-esque syntax highlighting. green/navy/black-on-white is so boring.

I worship his divine shadow.

true, and big nodes should be seen by a doctor lest they hinder the GC

I worship his divine shadow. ^

yes i see using a dummy node makes things a heck of a lot easier with the interlocked stuff and i had considered it but i didnt think it would make it that easy. the queue does have a head btw, from which items are removed (added to the tail). at first thought i would need to look into whether a circular reference of the head would introduce some other issue. but for simplicity's sake (sister of felicity i believe) im gonna use a good old LinkedList and the sleeplock thing. i usually just lock () { } things but for this i certianly want to keep it lightweight. with a little modification to make it adaptive for an actual multi-processor system (ie. not relinquishing time slice) i think itll be quite scalable. thanks for your input

I worship his divine shadow. ^

sorry, i dont think u were very convincing, im pretty sure this would work...

• in neutral state, _tail.next is null; the end of the list.
• the first thread executes the interlocked operation which succeeds and atomically sets _tail.next to something other than null.
• this causes the interlocked operation to fail on any other thread, and spin.
• the final assignment returns _tail.next to null (as a new list node has no next-node) and the list is coherent.

i think i just answered my own question there but i do get the feeling im missing something. i have more of an issue dequeuing a list node; ascertaining just how the de/enqueue code can interfere with each other and how i can get it to safely execute in parallel.

I worship his divine shadow. ^

nevermind.. i think ill give up for now and just use a modified spinlock! im writing a simple lock-free queue (intended for efficient multithreaded use) and im not sure ive quite figured out the logic behind the use of Interlocked.CompareExchange(). would code like the following produce the correct result of adding a new linked list node to the tail of a list under multithreading conditions?? while (null != Interlocked.CompareExchange(ref _tail.next, newNode, null)) Thread.Sleep(1); _tail = newNode; thanks in advance ;) -- modified at 12:40 Monday 8th January, 2007

I worship his divine shadow.

"Oooh Rocky!"

I worship his divine shadow. ^

im curious and unsure (and wading through a fog of nondeterministic destruction)... if one was to obtain a System.Runtime.InteropServices.GCHandle for each reference field of a class, and that class becomes eligible for finalization (implying that all its internal referenced objects also became eligible), would that class be finalized before any of its references (for sake of argument, the GCHandles were stored say, in an array in another reference type and both the array and its host object were also GCHandle'd in the array) ? would it be safe to assume all reference fields are still accessible at finalization time, allowing a controlled cleanup ? how might this be affected when the AppDomain unloads or CLR exits ? would the System.Environment.HasShutdownStarted property be of any use/relevance ?

I worship his divine shadow. ^

i dunno who Jordan is exactly but i love all that daily stuff that made me feel so special .. :^)

I worship his divine shadow. ^

ok so perhaps not c# specific but its the language im using so... i have some (hopefully) thread-safe code that accesses some shared fields using the lock statement but im trying to avoid full-on locking. i need to update a field only if the result does not exceed some other value. i found the following code for simple value update (in the CompareExchange() example):

do {
initialValue = totalValue;
computedValue = initialValue + addend;
} while (initialValue != Interlocked.CompareExchange(ref totalValue, computedValue, initialValue));

now, if i use the following would it be properly thread-safe and do wot i need..?

do {
initialValue = originalValue;
result = initialValue + addValue;
overFlag = result > maxValue;
if (overFlag) result = initialValue;
} while (initialValue != Interlocked.CompareExchange(ref originalValue, result, initialValue));

overFlag is bool and would be used after the udpate code to determine whether to continue or not. i cant quite get my head around it. :confused: thanks in advance

I worship his divine shadow.