Is it save to call these macros several times?

I don't see why not. I'm assuming that if the memory is already locked, at worst it'll return a failure value. Generally speaking, I know everything I'll need to lock at run time, so I've never actually ran into this particular situation.

The question is: Do I need to keep track of the fact that I've locked the var, or is it ok to lock it several times?

It's not a real problem, it would be pretty easy to avoid it, but it would require some work. If there's some sort of UNLOCK_XXX macro, it would be ok as well.

I've several states, the init rule of the state does all the init stuff (suprise, heh), the done rule clears up. I lock the var in the init rule, but since I can't unlock it in the done rule it's possible that the same var gets locked several times.

I believe if you lock something several times, if it throws errors, you would not matter them. As long as it does not throw an exception, you should be able to recover from the error.

Well, not really. View it like locking the screen, since this is a pretty good analogy: You lock the screen, do your stuff and unlock it.

The problem is, that I can't unlock the variable. There's no symetric function/macro for the LOCK_XXX macros.

Unless you want to switch to a different gfx mode or color depth, eh?

Well, maybe you can tell me how you'd handle this? I'm always willing to learn

Right now the only way I can think of would be to store the fact that I've locked the variable in a state variable.

init-rule: 
    if (varLocked is not true) {
        lock(var);
        varLocked = true;
    }

What'd I'd prefer would be:

init-rule: lock(var)
done-rule: unlock(var)

That would keep everything symetric.

EDIT: You're too fast

I do it the same as Derezo. Never had any problems.

I don't understand the difference. You're using the same variables each time, so it should be no different.
Lock them once in a single swoop (such as after calling install_timer), and never touch them again. Locking variables is not something you should even have to consider doing more than once during a program's execution.

Set it and forget it!™

Evil macro's work, too, though

The difference is that each module is like your program.
If you call your program trice in a row, you rely on the fact that the OS clears the system every time.
If you don't have that luxury, you need to take care of it yourself.

What is the ## notation in spellcaster's macros? It seems to concatenate VAR as an identifier. If so, I like!

It's the concat operator. There's also a string operator #

Yep. Now, imagine that these modules are dynamic.

This code shoulnd't leak resources:

while (1) {
    Object foo = new Object();
    delete foo;
}

In the same way, these calls shouldn't leak resources

while(1) {
    state_init(state);
    state_done(state);
}

Agreed?

Well, init() is the constructor. done() the destructor
What you're doing is to design-by-contract. You force the user (or yourself) to call those routines only once.
If you have start and init what you do is to force the player to keep the state in mind. he has to make sure that start or init (just from the name, I can't even tell what method should be called only once) is called just once.
So, all you do is delegating the responsibilty to the user. I consider this to be rude.

You should be able to create and free a state without wasting resources. I think we agree here?
And if I have to waste resources, it should be the responsibility of the state to ensure that the least amount possible is wasted.

With your approach, you either have to know all states at compile time (so no data driven aopproach is possible) or the user has to keep book whether he has called the "once in a life time method" or the state has to have a "isStartNeeded()/isInitNeeded()" the user can call... or it simply does the check itself - which is my current solution

What you're trying to do will result in exactly the same thing as I do. But you force the user to do the work, my code does it automatically. So I'm not sure I see your point.

Well, that's the point. Nobody was really quite sure whether it was save to call it sveral times or not, and what happens if it's called several times.
But there should be a symetric call to unlock it.
With your point of view, there's either no need at all to worry (then most of your posts in this thread don't make much sense any more ("why having a once in a programs-lifetime-method if it doesn't matter if it's called twice)).
With my point of view, stuff that is locked should be freed, since I don't know what the lock call does. It might differ from platform to platform, etc.

Well, it's not yet depricated. If it's not required at all, then most of this discussion was pretty pointless