09 August 2021, 10:53 | #21 |
Registered User
Join Date: Jan 2019
Location: Germany
Posts: 3,233
|
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. |
09 August 2021, 11:01 | #22 |
Registered User
Join Date: Jan 2019
Location: Germany
Posts: 3,233
|
...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. |
10 August 2021, 09:19 | #23 | |
bye
Join Date: Jun 2016
Location: Some / Where
Posts: 680
|
Quote:
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? |
|
10 August 2021, 11:30 | #24 |
Newbie Amiga programmer
Join Date: Jun 2012
Location: Front of my A500+
Age: 38
Posts: 372
|
Why it is needed to prevent a common base? Concurrent calls can cause conflict? I mean in the library's data segment.
|
10 August 2021, 15:19 | #25 |
Registered User
Join Date: Jan 2019
Location: Germany
Posts: 3,233
|
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. |
11 August 2021, 00:35 | #26 |
Newbie Amiga programmer
Join Date: Jun 2012
Location: Front of my A500+
Age: 38
Posts: 372
|
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. |
Currently Active Users Viewing This Thread: 1 (0 members and 1 guests) | |
Thread Tools | |
Similar Threads | ||||
Thread | Thread Starter | Forum | Replies | Last Post |
High-level steps for dragging an image between 2 windows? | Warty | Coders. C/C++ | 2 | 12 March 2021 18:43 |
Any functional language for the Amiga? | hth313 | Coders. C/C++ | 2 | 28 April 2019 20:08 |
Is there a high level copperlist decoder program? | kamelito | Coders. Asm / Hardware | 10 | 02 January 2018 21:56 |
Amiga C programming language | Kenan | support.Apps | 3 | 25 June 2013 18:50 |
High-level Apps for SysSpeed | tygre | request.Apps | 8 | 01 February 2013 05:11 |
|
|