Handle exceptions inside a critical section

[2B||!2B]

Is there an easy way to handle an exception when a lock is acquired?

For example, inside a critical section, there may be an exception generated. How to leave critical section in such case?

[aw27]

AFAIK, there are no special ASM facilities to handle them any easier than a HLL.
And real ASM programmers don't care about exceptions - good ASM code never faults. 

[2B||!2B]

Good point AW. However, it is nice addition to have just in case because if such things happened, a deadlock is very likely to happen.
I have seen a concept called RAII in OOP languages where the object constructor encapsulates EnterCriticalSection and the destructor calls LeaveCriticalSection. Stack unwind does it all in case an exception is generated.

Code Select Expand

struct CSHolder {
    explicit CSHolder(CRITICAL_SECTION& cs): lock(cs) {
        ::EnterCriticalSection(&lock);
    }
    ~CSHolder() { ::LeaveCriticalSection(&lock); }
    CRITICAL_SECTION& lock;
};


CRITICAL_SECTION gLock;
void foo() {
    CSHolder lockIt(gLock);
    // lock is held until lockIt is destroyed
}

It could also be done in assembly with masmbasic try/catch macro i think.

[avcaballero]

There's no magic in error handlings, it is just predictive codes.

[hutch--]

AW is correct here, the most reliable code is code with NO ERRORS. The only place where error handling is truly needed is in dealing with external hardware factors that cannot be predicted. Write error free code and you save yourself a pile of crap overhead, trying to emulate the blunders of high level code is a waste of life and time, its main purpose is to protect people who do not have the skills to write error free code while learning.

In terms of debugging code with errors, something that crashes immediately can be directly debugged without having to untangle a mountain of crap to get there.

[jj2007]

In terms of debugging code with errors, something that crashes immediately can be directly debugged

More precisely, you can catch crashes by using just-in-time debugging. With Olly 2, for example, you can set it in Options/Options/Debugging/Just-in-time. If your code throws an exception, either unintentional or by hitting an INT 3, a box pops up and you can choose between closing or debugging the program.

[mikeburr]

if youre using files then a much safer method of handling files is by putting a Soft Lock on the data. Basically what i mean is to put a data element in the record ... read the record and if the lock [byte] is not set then get the record set it and replace it . Any other potential user then knows the record is in use for update though reading of the current dta might..[????] be ok .[This is difficult in a multi threading environment btw .]. the same principle can be applied with elements of memory etc .. The real problem then is dealing with 'deadly embrace' however if you include a notion of the user of the locked record as well on the data item [eg a short user code] then you have the potential to notify them that you need their record etc etc The reason for this is that in a commercial environment things like users go to lunch leaving their work and stuff locked up , probably the most common thing other than say a file down for backup/overhaul [eg reindexing]  ..Im not sure if this is of any help to your problem but you are effectively managing the problem yourself rather than the operating system generalised API's ... as for multi threading instructions like XCHG will lock the bus and can be used to halt processes but this is very crude and fraught with danger when compared to the sophistication of the OS .. unux is far better in this respect
regards mike b