.NET Core angst
-
@dkf said in .NET Core angst:
I suppose it might help with making a concurrent GC, but I don't think it helps with deciding whether a thread-shared object has really been finished with; that requires the threads to come to an agreement, and that requires synchronization (especially once you move to larger systems).
To be fair, I've only played around with fairly small-scale/toy interpreters. I think I could use TM there to workaround the global interpreter lock issues, but I've not tried. So who knows.
It's better to write the code to be lock-free in the first place, though that's got other consequences.
Agreed. Proper lock-free (or even properly hand-locked) code seems like a better idea than TM in most cases. The TM overhead is only small when you have little contention, which is also the case where locking is cheap(er). OTOH TM seems useful when you have a legacy system that you don't wan to or can't rewrite to do multi-threading properly, and this could be one of the cases. (There's also the small issue of TM not being supported everywhere, so it might not be that useful in legacy code either.)
Filed under: Why the hell do I need to reload the page for the "reply"/"quote" to do anything?
-
@cvi said in .NET Core angst:
OTOH TM seems useful when you have a legacy system that you don't wan to or can't rewrite to do multi-threading properly, and this could be one of the cases.
Maybe? I just don't see how that works but maybe I'm stuck in the weeds of the detail…
-
@cartman82 said in .NET Core angst:
@Adynathos said in .NET Core angst:
However, the majority of libraries should be in the CLR, and the only ones needing porting are those directly interacting with the OS. So why is there such a problem with that?
It's not just about being multi-platform. It's also about getting rid of the accumulated legacy garbage.
MS tried to make NET core as thin as possible. AFAIU you should be able to just X-Copy deploy it wherever, or even package it with your program, instead of relying on an installed runtime.
It seems the sticking point was getting companies to actually transition their legacy tech to NET core, instead of NET 4.6 becoming the new Windows XP. Companies wanted an easy update path, where new NET core stuff is opt in and all the old API-s are available. MS wanted them to rethink a lot of their software and move to the new, clean platform, without a bunch of legacy garbage dragging everyone down.
As usual, MS blinked first.
Makes sense. As Joel Spolsky wrote, about 15 years ago:
A lot of software developers are seduced by the old "80/20" rule. It seems to make a lot of sense: 80% of the people use 20% of the features. So you convince yourself that you only need to implement 20% of the features, and you can still sell 80% as many copies.
Unfortunately, it's never the same 20%. Everybody uses a different set of features.
It really felt like Microsoft forgot about this in the early iterations of .NET Core.
@dkf said in .NET Core angst:
@PleegWat said in .NET Core angst:
you can use atomic instructions and skip the full lock
Still forces a bus synchronization; those things still have quite a lot of cost.
Those things have essentially no cost at all on modern architectures as long as there is no contention involved. (ie. there aren't any other cores that have that memory location in their cache.)
-
@masonwheeler said in .NET Core angst:
Those things have essentially no cost at all on modern architectures as long as there is no contention involved.
And provided you're only dealing with CPUs in the same die. Once you got larger than that, the latency required to decide anything starts to hurt. Partitioned memory works much better then, since you can keep the expensive synchronizations to the places where they're really needed.
-
@dkf said in .NET Core angst:
Maybe? I just don't see how that works but maybe I'm stuck in the weeds of the detail…
The way it looks in my mind (which may be very wrong, based on just having looked at the guts of toy interpreters and languages) is that instead of having a global lock, you can do something that looks a lot like fine-grained locking based on the memory addresses of objects.
So, when you need to deal with global state (e.g. figuring out how to access global objects/functions/variables/...), you wrap it into one or more transactional statements (XBEGIN & co). If all you do is read from the memory, the blocks will execute successfully. If only one block writes to the memory, it'll succeed -- concurrent reads OTOH will be aborted/rolled back (and need to be retried or something similar).
Then again, this is perhaps a bit of a too high-level look at the problem without the details. (I'm now kinda tempted to try it out in some simple example, I'm fairly sure I could get it to work there. </famous last words>).
-
@cvi said in .NET Core angst:
I'm now kinda tempted to try it out in some simple example, I'm fairly sure I could get it to work there.
I hear Python is a fairly simple language. Why don't you try there?
