Semaphore code wanted

I was wondering if anyone had come up with some code for a semaphore.

I'm talking about a computer-science type semaphore here - an abstract broker of a resource - and not a big stick of wood with a paddle on it for use with a railroad. I want to code up something like an automated parliamentarian for an assembly hall where everybody has a button to press to request the floor. The buttons all cooperate to make sure only one person gets the floor.

Has anybody coded anything like that? I can do it myself but see no reason to reinvent the wheel.

It would be much easier for another script to handle that instead of the buttons.

Button:

default
{
    touch_start(integer a)
    {
        llShout(569, "menu");
    }
}

Control:

key con = "";

default
{
    state_entry()
    {
        llListen(569, "", "", "");
    }
    listen(integer a, string b, key c, string d)
    {
        if(c == con || con == "")
        {
            if(d == "menu")
                llDialog(c, "Options", ["Take Floor","Release"], 569);
            else if(d == "Take Floor")
            {
                con = c;
            }
            else if(d == "Release")
            {
                con = "";
            }
        }
    }
}

You would have only one control and lots of buttons, low lag.

but going back to the original question, doesn't there remain a need for a semaphore kind of thing to arbitrate between two event handlers updating a common global variable? i'm thinking of, say, a string of keys (or a list, or an array, if we had them) of things detected using a sensor event which need to be processed in some non-trivial way using events.

so, they get put on the list of things to be handled, and when they are processed, they are removed from this common global list or array or string. question is, suppose the removing event is updating at the same time the adding event is? presumably copies are made and then the global gets updated, but Who Wins? i mean, properly arbitrated, both should.

we can do something quick, like a global "in use" flag, so the global resource doesn't get altered until it is not "in use". but what do the event handlers do meanwhile? busy wait with a sleep? we can't create event handlers within event handlers.

The way LSL works, you're not going to receive another queued event until currently ongoing event isn't completely resolved ... so you never get the situation of two processes trying to access the same resource at exactly same time.

For processing divided between multiple events you can probably add secondary variable to a resource and use it to mark the processing stage, in some very complicated siuations possibly combining it with separate state that doesn't get affected by events which are not part of processing..?

Please correct me if I'm wrong, but you can effectively block further processing of particualr events by changing state to oen that doesnt supply an event handler. So when you are 'in use' switch to an in use state will effectively block until such time as we return to the 'idle' state

According to the wiki, "all states must supply at least one event handler" - as they put it, it isn't really much of a state without one

You've misunderstood what I was saying.
By not handling the event that is causing the trigger , i.e. no touch event, then your new state can process without fear of interruption. state_entry counts as an event handler, I wasnt suggestion a completely empty state which as you say would be hilarious.

I do see what you're getting at, in the context of the original requirement.. "someone has the floor"..

so (abstract/pseudo code ahead)

state floor_taken
{
touch_start()
{
if (global var floor_taken_by != llDetectedKey(n)
{
tell the agent "sorry, llKey2Name(floor_taken_by) currently has the floor."
}
}
}

You'd need to wrap all that up into a for loop to catch each distinct touch...

In this case though, the state itself acts as the arbitrating semaphore.. add the original requirement of multiple prims being touched and you're looking at a system of networked, synchronized arbitrators.. doable, but sophisticated.

Then there's queueing agents up for floor time to handle. God this could get insane(ly fun)

Or not. The original post is august of last year? Could still turn into a useful application.

zk