j_seigh

Not enough caffeine. And yeah, it would have been phosphine since it was phosphorous that was the dopant.

Some places would mix it with nitric acid so the yellow stain would tell you that you had been exposed.

Other fun chemicals used in fabs were Silane (CSi4), methane w/ silicon instead of hydrogen, used to form a silicon dioxide layer for etching* w/ HF and final step of protection. It would spontaneously combust on contact with air, so when you popped a tank fitting it would leave a white powder residue. Silicon dioxide is used as a food additive so AFAIK that wasn't dangerous.

Phosgene was also used as a dopant. If the alarm for that went off you really got out ASAP.

Arsine was a dopant also.

This is what I sort of remember from working on slacker job in silicon fab a long time ago when the number of transistors per chip was 1. I did say a long time ago.

* You could also just oxidize the outer layer of the silicon wafer itself w/ water vaper at high temps.

I'd be more concerned with instruction reordering by the compiler. So even if the hardware guarantees some ordering, you will still need those memory fences.

Sort of. Basically you have a situation where one thread needs to see another thread's memory accesses in sequential consistent order. If you can determine the other thread has synchronized its memory accesses at some point, then all its memory accesses before that are in observably sequentially consistent.

The thing is you don't know exactly when that synchronization took place so your code logic has to take that into account. In the case of hazard pointers, false positives are ok and false negatives, i.e. thread is using reference that was not detected, cannot occur.

There's 2 or 3 other tricks you can make hazard pointers wait-free. Getting rid of the conditional branching in the instruction pipeline gives you a considerable speed up.

Couldn't traceroute run the entire TTL range in parallel, assuming the destination host was reachable and replies are disambiguable? I always hated waiting for traceroutes with lots of non responding routers.

It seems almost nobody can spell lose correctly anymore. I assume it's deliberate.

The comments about HFT needing tightly synchronized clocks got me thinking.

Back in the day, way back in the 80's, IBM replaced the VM with VMXA. VM could trap and emulate all the important instructions since they were privileged instructions except one, the STCK (store clock) instruction. So virtual machines couldn't set their virtual clocks so they were always in sync. VMXA used new hw features that let you set the virtual clock. You could specify an offset to the system clock. But some of IBM's biggest customers depended on all the virtual machines clocks always being in sync. So VMXA had to add an option to disallow setting the clock for specified virtual machines.

Except all of development knew how trivial it was to trap or modify the STCK's to produce a timestamp of you choosing. This was before it was common knowledge the client code should never be trusted. But nobody enlightened IBM corporate management. It was a serious career limiting move at IBM. It didn't matter if you were right. So I'm pretty sure some serious fortunes were made as a result.

So the question for HFT is; are they using and trusting client timestamps, or are the timestamps being generated on the market maker's servers? If the latter, how would the customer know?

Ok,so people use NTP to "synchronize" their clocks and then write applications that assume the clocks are in exact sync and can use timestamps for synchronization, even though NTP can see the clocks aren't always in sync. Do I have that right?

I did a lock-free MPMC ring buffer with 1 128 bit CAS and 1 64 bit CAS for enqueue and 1 64 bit CAS for dequeue. The payload is an unrestricted uintptr_t (64 bit) value so no way to avoid the 128 bit CAS in the enqueue.

Paywalled, but if you are familiar with the ABA problem in lock-free programming you can pretty much figure things out.

Coherent cache is transparent to the memory model. So if someone trying to explain memory model and ordering mentioned cache as affecting the memory model, it was pretty much a sign they didn't fully understand what they were talking about.