2 ms·

I guess I’m just a bit obsessed with Golden Age Microsoft, having grown up during that time without understanding much of what was going on. My original point,

I guess I’m just a bit obsessed with Golden Age Microsoft, having grown up during that time without understanding much of what was going on. My original point, though, was that they had some very nice, perhaps thesis-chapter-worthy points that ended up buried in the specifics of (and on more than one occasion, in the same grave as) their products. Windows’s, well, windows as a object/concurrency system are one (even if the Win32 transition to multithreading is IMO conceptually botched). The actor model admittedly already existed at that point, but Mark Miller et al.’s work on E (the only other source I know for having separate synchronous and asynchronous sends) hadn’t even started at that point. (There are innumerable papers on various versions of actors, though, so I might have missed it.) COM aggregation is another. It would probably have been much more successful had they used fat pointers, and there are a couple of old papers pointing this approach is a viable way to do implementation (as opposed to interface) inheritance. But I know of no precedent in the literature for the inside-out way WinRT builds its allegedly more conventional inheritance mechanism on it. (I guess I would’ve referenced BETA if I were writing a paper on it?) DCOM’s “causality IDs” for reentrancy control are yet another. You can basically have calls to your object guarded by a recursive mutex whose ownership is passed along with any remote calls that that object itself makes. I’m not sure they are a good idea (recursive mutexes are perilous in the simplest of situations, and this is most definitely not one of those), but I’m almost certain it’s an original one. That’s it, for now, but I’m almost certain I could find more, if only I knew where to look.

amluto 2y ago
Recursive mutexes are a terrible idea, except maybe in context. In a world where you can SendMessage a message to yourself or to another window in the same thread, process the message synchronously, and then return back to where you were, you have essentially uncontrolled reentrancy. If you want to throw mutexes into the mix, they pretty much need to be recursive. Then you get to acquire the mutex in a message handler to protect against other threads, and everything sort of works. In my own code, I try fairly hard to avoid this sort of reentrancy.

amluto 2y ago

Recursive mutexes are a terrible idea, except maybe in context. In a world where you can SendMessage a message to yourself or to another window in the same thread, process the message synchronously, and then return back to where you were, you have essentially uncontrolled reentrancy. If you want to throw mutexes into the mix, they pretty much need to be recursive. Then you get to acquire the mutex in a message handler to protect against other threads, and everything sort of works. In my own code, I try fairly hard to avoid this sort of reentrancy.