Multithreaded toolkits: A failed dream? (2004) • Hacker News Board

Re: Multithreaded toolkits: A failed dream? (2004)

#61

Post by kllrnohj » Tue, Nov 03, 2015, 1:56 AM UTC

kragen wrote: post #48

kllrnohj wrote: post #44

One of the things the article doesn't mention, which is odd, is that frames are precious objects that need to be produced in whole. If you have multiple threads all producing parts of the scene, when do you actually kick off the frame so that the user never sees a part of a frame? Even if your worker thread is just updating the text of a few fields when it's done, you need to batch that up into a single atomic update…

Most GUI toolkits don't bother. I'm guessing you work in video games?

Every GUI toolkit already "bothers" by virtue of being single threaded. You never see a UI toolkit where this:

  btn.setText("hello")
  btn.setColor(BLACK)

might show a white-text "hello" for a single frame. If the UI toolkit was thread-safe, though, that would become a possibility.

Re: Multithreaded toolkits: A failed dream? (2004)

#62

Post by frozenport » Tue, Nov 03, 2015, 2:46 AM UTC

vidarh wrote: post #60

frozenport wrote: post #59

Earlier quoted context omitted.

But I think the thing missing is that each of these threads ran on the same CPU (right?), and thus things like torn reads and writes weren't an issue, so they didn't need to use expensive std::mutex or std::atomic everywhere. Today, we have single concurrent execution by enforcing a single GUI thread, at the time of the Amiga they had single concurrent execution because that was the only execution they had.

They ran on the same CPU, but you still had to use mutexes and atomic operations because it had fully pre-emptive multi-tasking, and so your application had to be ready to lose execution from one instruction to the next. Torn reads/writes definitively were an issue for higher level code (unless you could be guaranteed that your construct would translate to a single m68k instruction), and needed to be kept in mind eve…

I really enjoyed reading this post, and it looks like the Amiga was ahead of its time.

Re: Multithreaded toolkits: A failed dream? (2004)

#63

Post by MichaelMoser123 » Tue, Nov 03, 2015, 8:20 AM UTC

MichaelMoser123 wrote: post #53

the author says that with AWT it was a design decision against thread save GUI, one problem here - there is no way they could have made AWT thread save - AWT uses the native windowing toolkit as its basis; on Windows this implies that all clients of the Win32 sdk are from the same thread as the event loop; there is no other means to work with USER32.dll - you have to send windows messages to the window handle, that's…

it would have been possible without locks if the client would have sent IPC messages to the other threads event queue and then wait until the result comes back. This way all access to the GUI widgets is serialized via the event loop.

In windows they had apartment model COM objects that used to work by this principle (ouch, i feel so old now ...)

Re: Multithreaded toolkits: A failed dream? (2004)

#64

Post by vidarh » Tue, Nov 03, 2015, 10:49 PM UTC

frozenport wrote: post #62

vidarh wrote: post #60

Earlier quoted context omitted.

They ran on the same CPU, but you still had to use mutexes and atomic operations because it had fully pre-emptive multi-tasking, and so your application had to be ready to lose execution from one instruction to the next. Torn reads/writes definitively were an issue for higher level code (unless you could be guaranteed that your construct would translate to a single m68k instruction), and needed to be kept in mind eve…

I really enjoyed reading this post, and it looks like the Amiga was ahead of its time.

It was a fantastic machine. Unfortunately Commodore all the way through (from long before the Amiga) was an absolute dysfunctional disaster of a company, and it was a miracle they lasted as long as they did (and a testament to the calibre of people that kept saving the company from self-inflicted wounds)

The biggest problem being perpetual under-investment in R&D, and management meddling that systematically whittled away at the lead they once had. E.g. the archetypical example is the Amiga4000. On one hand it is the "flagship"; the biggest, fastest classic m68k Amiga produced.

On the other hand, it arrived late, was ridiculously expensive, and was slow for what was there. The problem? New management wanted to start all projects over from scratch and put their stamp on them.

IDE, for example, was suddenly pushed onto engineering. Without understanding that the Amiga used SCSI for a reason: IDE of the time loaded the CPU too much. Fine on a single-tasking OS, or on machines with more CPU, but the Amiga was built around offloading everything. It was the only thing that kept it competitive in the face of mounting problems for Motorola with upping the speed of the M68k range (work was underway to evaluate alternative CPUs; PA-RISC was the lead contender at the time; in the end Commodore went bankrupt before making a decision, and third parties chose PPC).

The A4000 was the result: IDE dragging down IO performance; a broken memory sub-system due to rushed redesigns; a butt-ugly case compared to the sleek A3000, and trying to compensate for the other problems by going for a 68040, but going "cheap" and picking one of the slower versions and yet stil ending up too expensive.

The truly crazy thing, though, is that as they were doing this, the "A3000+" was pretty much done. It didn't have quite as fast a CPU, but was a step up from the A3000. It had AGA (the last custom chips that the A4000 also got), and a range of other improvements, such as a DSP providing high-end sound (8x CD quality channels), and that could also double as a built in modem. And it kept SCSI...

The best part? It was far cheaper than the A4000, and would've been ready much faster. Of course Commodore had to axe it...

Being a fan of the Amiga at the time was painful...