[fpc-devel]portable disable; and enable;

[Thomas Schatzl]

Hello,

    Enable / Disable and critical sections are completely different
things...... the first is used for turning off (virtual) interrupts, the
other one for thread synchronization.

The key to critical sections is that while they're 'owned' by one thread,
another one can't claim ownership for the same critical section object so
that the 'owning one' can't get interrupted by others which try to get
ownership themselves when doing some mutually exclusive stuff (e.g. writing
data to a file). It doesn't prevent other threads from running which don't
want to get ownership of the critical section (e.g. don't want to write to
the same file).

In a single threaded program critical sections are not worth the writing.
Mutexes are similar to critical section objects but with a scope of
processes.

Semaphore's are quite similar with the exception that they allow ownership
of a specified amount of threads at the same time, e.g. for accessing a
limited resource by several threads at the same time.

P.S.: Most likely DPMI servers virtualize the cli and sti instructions too;
so the interrupts aren't really disabled in DPMI - PM at all - only the
handlers installed by the app doing this are not called.
At least in all PM environments like Win9x DOS box it is very unlikely that
your application can modify real hardware interrupt state.
I recommend the DPMI spec of your choice for further reading about this.
This applies to any other PM OS as well btw, you may use enable() and
disable() there too - not only go32v2....

Regards,
    Thomas

Subject: [fpc-devel]portable disable; and enable;


> Hello,
>
>   Is it possible to implement portable disable; and enable;
>   procedures? I just know that under dos32v2 you can use disable and
>   enable;. Under win32 you can use critical sections for that. And
>   seems to be that it is possible to emulate disable; and enable; using
>   critical sections. I just wonder if the same is possible under
>   linux, os/2 or any other system? Or maybe some unit that provides
>   such services already exists?
>
> Best regards,
>  Aleksey                          mailto:picoder at sbis.komi.ru