Amiga library in high-level language

[Thomas Richter]

Unless you absolutely know what you are doing, please *do not* use semaphores in the library management functions, this is error prone. All the Os datatypes had a bug in using semaphores incorrectly. Note that a semaphore will block, and thus breaks the Forbid() state.

Typical errors are that the semaphore blocks in LibClose, another task tries to open the library at the same time, and you flush the library afterwards in LibClose "under the feed" of the program that just opened the library.

The code to make this working is fragile, and I would not propose to attempt this.

[Thomas Richter]

...and there you have it. Checked your code, you now have a race condition thanks to semaphores. First, what does the semaphore exactly protect? Anything it protects in LibOpen can go away without getting the semaphore in LibClose(), so it's not exactly helping, right?

Second, a task could remove your library while the semaphore is blocked. You need to increment the lib Open counter *outside* of the semaphore as this counter protects the library from going away *while* the semaphore is blocked.

Then, as said, you need to get LibClose() right to work with the semaphore.

As I said, avoid this... Think twice where a task could block, and what could happen in parallel while the semaphore is blocked.

[bebbo]

Originally Posted by Thomas Richter

...and there you have it. Checked your code, you now have a race condition thanks to semaphores. First, what does the semaphore exactly protect? Anything it protects in LibOpen can go away without getting the semaphore in LibClose(), so it's not exactly helping, right?

Second, a task could remove your library while the semaphore is blocked. You need to increment the lib Open counter *outside* of the semaphore as this counter protects the library from going away *while* the semaphore is blocked.

Then, as said, you need to get LibClose() right to work with the semaphore.

As I said, avoid this... Think twice where a task could block, and what could happen in parallel while the semaphore is blocked.

ok - I removed that semaphore again ^^


btw: do you now if that freeing of the libraries memory is a leftover from old versions or should it be still there?

[TCH]

Why it is needed to prevent a common base? Concurrent calls can cause conflict? I mean in the library's data segment.

[Thomas Richter]

It depends on what you do in your library base. If it only contains constants that are initialized once in LibInit, then there is no problem to use a common library base for all library opener. If not, it can become a bit tricky.

In most cases, however, it is better practice to put such "state variables" in a state that is allocated through a dedicated library function , and also released by a library function.

Think of intuition windows. The "window structure" is actually a big "state variable" intuition creates, deletes and works on. Since intuition has multiple such state variables (windows, screens,...) it is better to have separate "constructors" and "destructors" for them instead of putting them all into the library base.

[TCH]

I see, so library global variables are shared among all openers and thus to avoid conflict, one should follow "OOP" approach in any case a library variable must be shared among the library functions and manage those externally in the opener via "constructors" and "destructors" in the library and pass the corresponding managed global data to each affected library function.
Thanks for clarifying.