Concise Way to Describe Colour Spaces

[Brendan]

Hi,

Basically; I want a massive simulated universe of many worlds acting as a (multi-player) sandbox game; where each player chooses which role they want to play within that universe (from small things like being rat catcher in a specific city on a specific planet, to massive things like trying to achieve universal domination by conquering worlds) and where any player can switch between roles whenever they like; and where anything a player isn't doing is taken over by AI.

Cool, but don't fool yourself into thinking that's any kind of replacement for other games with smaller scopes.

There'd be games with smaller scopes, and games with different themes (medieval, futuristic, fluffy pink kittens, etc), and games within games (e.g. virtual amusement arcades, maybe even with NPCs capable of playing them).


Cheers,

Brendan

[AndrewAPrice]

I think the nice thing about "one or more objects per thread, no data shared between threads" is that locks/mutexes are never needed anywhere (except in the kernel); which makes it much easier to write scalable software.

For your idea, there's 2 very different cases. If an object receives 2 or more messages at the same time and the kernel creates 2 or more threads that all operate on the object's data at the same time, then you end up needing locks/mutexes and it ends up complicated.

True. I'm forcing every application to be written to be thread-safe and lockless, which isn't the best idea.

Alternatively; if an object receives 2 or more messages at the same time and the kernel only creates 1 thread and postpones the other messages until the first thread terminates; then there's no locking needed. In this case it's mostly the same as my system, except that you terminate a thread where I block the thread, and you create a thread where I unblock a thread. However; it's only "mostly the same"; and causes subtle differences in the way threads and messaging behave.

For example, you can't do something like this:

Code: Select all

    do {
        if( check_for_message_without_blocking() == GOT_MESSAGE) {
            handle_message();
        }
        finished = do_some_more_work();
    } while( !finished );

This is actually relatively important for things that take lots of CPU time but need to listen for messages saying "Hey, cancel that long running/expensive work I asked you to do earlier; I don't need it anymore!".

You also can't (internally) re-order requests and do them in order of request priority (instead of doing them in order of arrival); like this:

Code: Select all

    while( true ) { 
        get_for_message_with_blocking();
        handle_message();             // Adds request to an internal queue according to request's priority

        while( (next_request = get_highest_priority_pending_request()) != NULL) {
            do_request(next_request);
            while( check_for_message_without_blocking() == GOT_MESSAGE) {
                handle_message();     // Adds request to an internal queue according to request's priority
            }
        }
    }

This is important for a lot of things (service, drivers, etc). For example, imagine a hard disk driver where you've got 10 medium priority requests for normal files, then receive a high priority request from kernel asking for data from swap space, then receive a very high priority "IRQ occurred" message from kernel.

Also true! Great food for thought.

It would be possible to build a lockless queue with a 'message handler' attached to it, and the message handler is called if it's empty and an item was just added, and the message handler iterates over the queue one item at a time. e.g. The programmer will create a SychronousQueueProcessor<MessageClass, myHandlerFunction>. But am I complicating things?

I like the idea of removing the thread abstraction and creating a purely event-driven system, but perhaps providing a locking/waiting ability to tasks would not be such a bad idea? But, would that remove the purity of the system?

[Brendan]

Hi,

It would be possible to build a lockless queue with a 'message handler' attached to it, and the message handler is called if it's empty and an item was just added, and the message handler iterates over the queue one item at a time. e.g. The programmer will create a SychronousQueueProcessor<MessageClass, myHandlerFunction>. But am I complicating things?

I can't think of any significant problem with that; and don't think it'd be too complicated to implement or use.

I like the idea of removing the thread abstraction and creating a purely event-driven system, but perhaps providing a locking/waiting ability to tasks would not be such a bad idea? But, would that remove the purity of the system?

When a piece of software is being executed the CPU has state (the values currently in the instruction pointer, other registers, etc). This is impossible to avoid; even if you change the words you use to describe it (e.g. from "thread" to "message handler").

You don't need locks unless you combine it with some sort of shared memory (e.g. "process space" that all message handlers that belong to the process share); which isn't necessarily good or bad, but is unrelated/orthogonal.


Cheers,

Brendan