Language:
switch to room list switch to menu My folders
Go to page: First ... 13 14 15 16 [17] 18 19 20 21 ... Last
[#] Thu Jan 01 2009 22:36:46 EST from IGnatius T Foobar @ Uncensored

[Reply] [ReplyQuoted] [Headers] [Print]

The few times I've attempted to write desktop software really turned me off to event driven programming. Someone else decides the flow of control in your program.

[#] Thu Jan 01 2009 23:09:32 EST from Ford II @ Uncensored

[Reply] [ReplyQuoted] [Headers] [Print]

And yet you hate multithreaded programs.

I think maybe threads didn't exist when I wrote that program.
Yes I hate threads. I loved threads when I first started playing with them in os/2 but there's no question in my mind anymore that they cause more harm than good.
I still love parallelism, and there's plenty of ways to do parallelism without threads, and I'm all for it, and I still do it.

[#] Thu Jan 01 2009 23:10:29 EST from Ford II @ Uncensored

[Reply] [ReplyQuoted] [Headers] [Print]

It's really what Apple tried to ram down everyone's throat with their
'co-operative' multi-threading model that blew up in their face. They simply

didn't do it right, I guess.

Windows 3.x did that too and it didn't work either.
I think the idea of cooperative multitasking is sound, but it's not a beefy enough architecture to support the kind of abuse that an OS has to take.

[#] Thu Jan 01 2009 23:11:40 EST from Ford II @ Uncensored

[Reply] [ReplyQuoted] [Headers] [Print]

Windows 3.x did that too and it didn't work either.

For that matter, Os/2 did it also, One of the few mistakes they made.
(And while I contend that os/2 was the most perfectly designed OS, I'm usually talking about the kernel, the GUI layer had it's problems, the single threaded msg queue being one of them)

[#] Thu Jan 01 2009 23:12:13 EST from Ford II @ Uncensored

[Reply] [ReplyQuoted] [Headers] [Print]

The few times I've attempted to write desktop software really turned me

off to event driven programming. Someone else decides the flow of
control in your program.

But it's CRAZY EFFICIENT if you're willing to play ball.

[#] Thu Jan 01 2009 23:13:30 EST from Ford II @ Uncensored

[Reply] [ReplyQuoted] [Headers] [Print]

The few times I've attempted to write desktop software really turned me

off to event driven programming. Someone else decides the flow of

Maybe I misunderstand. Monolithic standalone desktop software that doesn't have to share with anybody would probably suffer from event drive design rather than help it.
But in the case of a windowed gui, it's definet benefit.

[#] Fri Jan 02 2009 02:10:37 EST from Nite*Star @ Uncensored

[Reply] [ReplyQuoted] [Headers] [Print]

It's really what Apple tried to ram down everyone's throat with their
'co-operative' multi-threading model that blew up in their face. They simply

didn't do it right, I guess.

If I'm understanding this discussion correctly then no, Apple didn't get it right. But Commodore did, with the Amiga OS.

[#] Fri Jan 02 2009 12:23:26 EST from fleeb @ Uncensored

[Reply] [ReplyQuoted] [Headers] [Print]


Amiga didn't get it right, either, because they didn't even play ball.

The Amiga was a pre-emptive multitasking operating system (like the ones we use today).

When we wrote 'get it right', we meant 'get co-operative multi-tasking right'.

[#] Fri Jan 02 2009 12:34:21 EST from fleeb @ Uncensored

[Reply] [ReplyQuoted] [Headers] [Print]

Jan 1 2009 10:36pm from IGnatius T Foobar @uncnsrd
The few times I've attempted to write desktop software really turned me

off to event driven programming. Someone else decides the flow of
control in your program.

The boost::asio approach feels best to me.

You give it the function you want to run when the asynchronous event takes place.

In this way, you still have some sense of controlling the flow of control, although it admittedly feels a little strange until you get used to it.

[#] Fri Jan 02 2009 12:36:02 EST from Nite*Star @ Uncensored

[Reply] [ReplyQuoted] [Headers] [Print]

Hrm, I thought it was cooperative and not pre-emptive? Guess I was wrong. :( I just know that at the time, the Amiga was basically the only computer to do multi-tasking right, period.

[#] Fri Jan 02 2009 12:45:20 EST from fleeb @ Uncensored

[Reply] [ReplyQuoted] [Headers] [Print]


Pre-emptive multitasking works for the operating system, because you don't have some rogue programmer screwing up the entire operating system by hogging the processing time. That's why the Amiga looked like it worked so well... they made the right decision.

Still, if you're programming your own application, and you can write your program using co-operative multitasking within the pre-emptive multtasking operating system, you can benefit from both.

[#] Fri Jan 02 2009 13:00:06 EST from Nite*Star @ Uncensored

[Reply] [ReplyQuoted] [Headers] [Print]

How does cooperative multitasking differ from pre-emptive multitasking?

[#] Fri Jan 02 2009 13:08:35 EST from Nite*Star @ Uncensored

[Reply] [ReplyQuoted] [Headers] [Print]

Can someone explain this to me? Source link is at the end of quoted text:

While threads are scheduled preemptively, some operating systems provide a variant to threads, named fibers, that are scheduled cooperatively. On operating systems that do not provide fibers, an application may implement its own fibers using repeated calls to worker functions. Fibers are even more lightweight than threads, and somewhat easier to program with, although they tend to lose some or all of the benefits of threads on machines with multiple processors.[citation needed]

http://en.wikipedia.org/wiki/Computer_multitasking

[#] Fri Jan 02 2009 13:16:02 EST from dothebart @ Uncensored

[Reply] [ReplyQuoted] [Headers] [Print]

its probably in the nature of cooperative multitasking that it doesn't scale good on multiple cpu with stuff like concurrent access to resources...

[#] Fri Jan 02 2009 13:52:23 EST from Nite*Star @ Uncensored

[Reply] [ReplyQuoted] [Headers] [Print]

Jan 2 2009 1:16pm from dothebart @uncnsrd
its probably in the nature of cooperative multitasking that it doesn't scale

good on multiple cpu with stuff like concurrent access to resources...


::blink::

::blink::

::stare::


Um, is that English? :p

[#] Fri Jan 02 2009 14:26:30 EST from LoanShark @ Uncensored

[Reply] [ReplyQuoted] [Headers] [Print]


Yes.

[#] Fri Jan 02 2009 15:18:54 EST from Ford II @ Uncensored

[Reply] [ReplyQuoted] [Headers] [Print]

its probably in the nature of cooperative multitasking that it
doesn't scale
good on multiple cpu with stuff like concurrent access to

That's a good point. Although depending on if the cooperative mutitasking engine is smart it still may be able to distribute over multiple cores/cpus. THat wasn't an issue in the 80's so I imagine it didn't come up much.
I never heard the formal name 'fibers' before, but it's a fun programming style. I do that still sometimes, but given that more and more machines have multiple cores and cpus, you're tying yourself down uneccesarily.
And as for putting it in the OS kernel? That sounds dumb to me, but maybe there's more to it.

[#] Fri Jan 02 2009 15:31:44 EST from IGnatius T Foobar @ Uncensored

[Reply] [ReplyQuoted] [Headers] [Print]

How does cooperative multitasking differ from pre-emptive multitasking?


Cooperative multitasking requires each task to be aware that it is running in a cooperative multitasking environment, and *voluntarily* give up its time slice once in a while. Usually this happens anyway when the process is about to block waiting for I/O or some other external event, but if a program expects to be CPU bound for a long time, it has to perform a system call once in a while to give up its time slice so other programs can run. If it doesn't, other programs don't get their time slice and they simply stop responding.

Pre-emptive multitasking has no such concept. A program's time slice will end if it blocks on I/O or anything else, but it never gives up its time slice in the middle of running code -- the operating system jumps in and does that automatically.

Cooperative multitasking is quite efficient if all of the programs are well behaved, because they give up the CPU when it makes sense to do so rather than when the operating system decides that the program has had enough CPU and it's now someone else's turn. Unfortunately, we live in a world of badly written programs, so it doesn't make sense to use cooperative multitasking in a general purpose operating system.

[#] Fri Jan 02 2009 15:47:59 EST from fleeb @ Uncensored

[Reply] [ReplyQuoted] [Headers] [Print]


IG has it right.

Theoretically, co-operative multitasking is much more efficient. But, unfortunately, people suck.

You can think of pre-emptive multitasking as a way of ripping the use of the CPU out from under a currently running thread and handing it off to some other thread. As it takes the processor away from the thread, it stores some information about the state of the registers and such, so it can restore that state later, when it returns the CPU to the thread.

In co-operative multitasking, you yield time when you feel it appropriate to do so, instead of having the processor taken away from you. I don't know how much state is preserved when you yield, but I doubt you have to store as much state (probably just the location of the next instruction). It's very efficient, but only if everyone behaves and yeilds when they should.
Even Apple didn't yield when they should have, so it's a difficult model to use across an entire operating system.

I've seen 'fibre' tossed around, and I kind of get the feeling that its best use is rather specialized. I don't really grok it, though, so maybe I'm off base.

[#] Fri Jan 02 2009 16:03:06 EST from Ford II @ Uncensored

[Reply] [ReplyQuoted] [Headers] [Print]

I haven't thought about this stuff in a while, but cooprerative and event driven while both good ideas, really don't work well together.
I remember the problem always being (in the windows 32 api) if you wre handling an event and it took a long long time, everybody waited.
In VB they added this thing called 'doevents()' which basically gave up your time for you, but in C land there was no such thing and if you wanted to take a long time about something, you either made everybody wait, or you did some really complicated state machine thing, or the worst but easiest which is what everybody did...
You Handled More Windows Messages In the Windows Message Handler.

I remember feeling so slimey for doing that, because lord knows what state was going on in windows when you started handling other messages, and of course if you didn't push back on other messages for your system all sorts of interesting things happened.
That's the one combination that really doesn't work well.

Go to page: First ... 13 14 15 16 [17] 18 19 20 21 ... Last