29-Nov-2020 02:13 GMT.
UNDER CONSTRUCTION
Anonymous, there are 114 items in your selection [1 - 50] [51 - 100] [101 - 114]
[Forum] OS4 design for ObtainSysList/ReleaseSysListANN.lu
Posted on 11-Jul-2004 20:44 GMT by adesigner (Edited on 2004-07-12 02:34:47 GMT by Christophe Decanini)114 comments
View flat
View list
"In the documentation of FindPort() it is said that you should use ObtainSysList(OSL_PORTLIST) and ReleaseSysList() instead of Forbit() and Permit() in OS4."
www.amigaworld.net thread

I believe this is broken design, you can't mix Forbid and semaphore locking. (Edit by Christophe: It has been confirmed that this solution was rejected for OS4) [sort of pseudo code follows]

" static struct MsgPort *Port;

int InitThePort(void)
{
struct MsgPort *newport;
int result = 0;

ObtainSysList(OSL_PORTLIST); /* Forbid(); */
Port = FindPort(MYPORTNAME);
if (Port) {
result = 2;
} else {
newport = AllocMem(sizeof(*newport), MEMF_PUBLIC);
if (newport) {
/* ... init newport ... */
AddPort(newport);
Port = newport;
result = 1;
} else result = 0;
} else result = 0;

ReleaseSysList(OSL_PORTLIST); /* Permit(); */
return result;
}
"

The problem here is that if some other app is using Forbid() locking, it can easily end up AddPort()ng duplicate port with the same name.

This can happen if task A using ObtainSysList reaches just before AddPort, and Task B using Forbid gets scheduled to run. This task will then Forbid, FindPort and get NULL too. Task B (that is run within Forbid) will now continue and create new port and add it to system via AddPort.

Next Task B Permits and lets other tasks run. Now Task A gets to run and continues to AddPort *duplicate* port.

Further problems may arise if application FindPorting for this port is using Forbid. There the port is actually found *before* InitThePort reaches ReleaseSysList. Now if some further initializing of resources is done before this call, messages might get lost in case these initializations fail, and the app assumes no messages can be in the port (the port list is locked after all, so there should't be any, right?).

RemPort has similar issues, but there the problem is that FindPort can find the port even after ObtainSysList is called for RemPort, and thus more messages might appear in the port even after this ObtainSysList.

Note that AddPort/FindPort itself must not break Forbid. There are a lot more ways that things can break down, I just listed some. Also here I only considered public port list, other system lists have even greater problems.

I ask developers to review these findings and if I am wrong, correct me.

OS4 design for ObtainSysList/ReleaseSysList : Comment 1 of 114ANN.lu
Posted by Fabio Alemagna on 11-Jul-2004 19:08 GMT
Nothing forces ObtainSysList(OSL_PORTLIST) to be implemented via semaphore, it could be simply implemented via Forbid(), and the dual could be implemented via Permit(). Should one day one get rid of old/68k sw, then the implementation could be changed to use a semaphore and the applications wouldn't notice.

I do not believe, though, that what one of the Frieden bros (don't remember which) explained in the linked thread is feasible. That is, even if 68k programs and ppc programs see 2 different jumptables for the same library, even if you could make a 68k program jump to a different function than the ppc one, I can't see how would that solve the problem: once the PPC program has acquired the semaphore, there's absolutely nothing that could be done to preevent a 68k program from fiddling with the ports list without interferring with the ppc one.
OS4 design for ObtainSysList/ReleaseSysList : Comment 2 of 114ANN.lu
Posted by Anonymous on 11-Jul-2004 19:17 GMT
In reply to Comment 1 (Fabio Alemagna):
The problem there is that the wording is "should", not "must".

So fully native apps could continue to use Forbid() locking, which would break if semaphores were introduced.
OS4 design for ObtainSysList/ReleaseSysList : Comment 3 of 114ANN.lu
Posted by Richi on 11-Jul-2004 19:17 GMT
All these posts by Eva and Friends!
Let them work please.
OS4 design for ObtainSysList/ReleaseSysList : Comment 4 of 114ANN.lu
Posted by Fabio Alemagna on 11-Jul-2004 19:25 GMT
In reply to Comment 2 (Anonymous):
> So fully native apps could continue to use Forbid() locking, which would break
> if semaphores were introduced.

I believe it's stated in the autodocs that one must use that new locking mechanism? If not, they better hurry in stating so.
OS4 design for ObtainSysList/ReleaseSysList : Comment 5 of 114ANN.lu
Posted by Amon_Re on 11-Jul-2004 19:34 GMT
My god, the crap never ends :(
OS4 design for ObtainSysList/ReleaseSysList : Comment 6 of 114ANN.lu
Posted by Fabio Alemagna on 11-Jul-2004 19:44 GMT
In reply to Comment 5 (Amon_Re):
> My god, the crap never ends :(

What crap, exactly?
OS4 design for ObtainSysList/ReleaseSysList : Comment 7 of 114ANN.lu
Posted by Anonymous on 11-Jul-2004 19:46 GMT
In reply to Comment 4 (Fabio Alemagna):
> I believe it's stated in the autodocs that one must use that new locking mechanism?

Ah, if so (and everyone would follow it), then it would work.

This would break source level compatibility again though, not making it easy to recompile old code (you'd need to replace all system list related Forbid/Permit with ObtainSysList/ReleaseSysList in the source).

But as far as I understand these routines don't exist in current OS4. Which means, the current OS4 apps will not work on future OS4 where these functions get implemented & used (and made to use semaphores).

Basically these functions are dead before even implemented.

Design... Design.. Or lack of it?
OS4 design for ObtainSysList/ReleaseSysList : Comment 8 of 114ANN.lu
Posted by Amon_Re on 11-Jul-2004 19:52 GMT
In reply to Comment 6 (Fabio Alemagna):
The attacks at the AOS4 project
OS4 design for ObtainSysList/ReleaseSysList : Comment 9 of 114ANN.lu
Posted by Fabio Alemagna on 11-Jul-2004 19:55 GMT
In reply to Comment 1 (Fabio Alemagna):
> I do not believe, though, that what one of the Frieden bros [...]

I retract that. There is something that can be done.
OS4 design for ObtainSysList/ReleaseSysList : Comment 10 of 114ANN.lu
Posted by Fabio Alemagna on 11-Jul-2004 19:56 GMT
In reply to Comment 8 (Amon_Re):
> The attacks at the AOS4 project

What attack, exactly?
OS4 design for ObtainSysList/ReleaseSysList : Comment 11 of 114ANN.lu
Posted by Amon_Re on 11-Jul-2004 19:57 GMT
In reply to Comment 10 (Fabio Alemagna):
- 2 threads about the ArticiaS
- 1 thread calling the vid faked
- This thread.

4 threads with a clear negative tone directed at the AOS4 project and affliated products, maybe i'm just being paranoïde....
OS4 design for ObtainSysList/ReleaseSysList : Comment 12 of 114ANN.lu
Posted by Kolbjørn Barmen on 11-Jul-2004 20:11 GMT
In reply to Comment 11 (Amon_Re):
You are :)
OS4 design for ObtainSysList/ReleaseSysList : Comment 13 of 114ANN.lu
Posted by Fabio Alemagna on 11-Jul-2004 20:23 GMT
In reply to Comment 11 (Amon_Re):
> - 2 threads about the ArticiaS

Well, the issue has been rised on AW.net, to be completely honest. It seems normal that when there's something to dispute... people do dispute about it.

> - 1 thread calling the vid faked

Clearly someone who doesn't like AOS4, and who finds that video, perhaps, "too fast to be true", has rised an issue which was interesting nonetheless.

> - This thread.

This is not an attack, it's just a legitimate question, which could be politely answered.

You should learn that every critics gives the opportunity to prove it (the critic) wrong. Can you imagine a better way to set people convinced that your solution is better than the others?

Of course, if you're not able to prove critics wrong, you're in trouble, but then... isn't that better for consumers?
OS4 design for ObtainSysList/ReleaseSysList : Comment 14 of 114ANN.lu
Posted by Peter Gordon on 11-Jul-2004 20:38 GMT
The fact is that the idea behind this change is sound. It IS a good idea to try and move people away from using Forbid/Permit... period.

And there *are* ways to facilitate supporting both methods until such time as it is possible to ditch the legacy method (if that time arrives of course). For example, the FindPort(), AddPort() and RemPort() routines could check that the calling task has obtained the semaphore through some internal private flag, and if not, obtaining it for the duration of that call (see my example on the AW.net as to why this would work).

I think thats a pretty good trade off for legacy support and moving the platform forward.
OS4 design for ObtainSysList/ReleaseSysList : Comment 15 of 114ANN.lu
Posted by Johan Rönnblom on 11-Jul-2004 20:46 GMT
Amon_re: Huh? Obviosuly people have different opinions, and in any
discussion about anything (including OS4 or the A1) some opinions will
be more favourable towards OS4/A1 than others. It would be awfully
boring if everyone had the same opinions about everything, wouldn't
it?

As someone who changed his mind twice in that "speeded video" thread I
think I can also honestly say that it's *not* just a matter of two
entrenched sides throwing things at oneanother, there *is* a real
exchange here. :-)

As for this design issue I'm not really informed enough to have an
opinion, so I don't. But I can't see harm in a discussion (and I think
the post is quite politely phrased, and in a constructive mood). I'd
sure like to see more threads like this, both about OS4 and MOS (and
AROS too, for that matter).
OS4 design for ObtainSysList/ReleaseSysList : Comment 16 of 114ANN.lu
Posted by Anonymous on 11-Jul-2004 20:54 GMT
In reply to Comment 14 (Peter Gordon):
"The fact is that the idea behind this change is sound. It IS a good idea to try and move people away from using Forbid/Permit."

Agreed.

"For example, the FindPort(), AddPort() and RemPort() routines could check that the calling task has obtained the semaphore through some internal private flag, and if not, obtaining it for the duration of that call"

This will not work. Simple app doing:

Forbid();
if (port=FindPort("moo")) PutMsg(port, msg);
Permit();

...would not work reliably then (port could disappear before PutMsg adds the msg into it).
OS4 design for ObtainSysList/ReleaseSysList : Comment 17 of 114ANN.lu
Posted by Fabio Alemagna on 11-Jul-2004 20:55 GMT
A bit OT, but still related: in the light of making things "better", it would be more sensible, given that source compatibility is being broken anyway, to create a totally different approach to such problems. That is, the act of checking whether a port exists and if not create and add it to the system list should be completely undivisible, and the programmer shouldn't be asked to manually taking care of any locking. Those are vital parts of the systems, and if programmers are still supposed to fiddle with them and potentially harm them, then I can't see how will it ever be possible to implement full MP, or even whether it will be effective at all, given that it's still possible to create deadlocks by "forgetting" to lock/unlock vital resources.
OS4 design for ObtainSysList/ReleaseSysList : Comment 18 of 114ANN.lu
Posted by Fabio Alemagna on 11-Jul-2004 21:00 GMT
In reply to Comment 16 (Anonymous):
> ..would not work reliably then (port could disappear before PutMsg adds the msg
> into it).

Mmmh, yeah, that's true. So it appears I have to put it forth again :-).
OS4 design for ObtainSysList/ReleaseSysList : Comment 19 of 114ANN.lu
Posted by Peter Gordon on 11-Jul-2004 21:00 GMT
In reply to Comment 16 (Anonymous):
No, it couldn't. Read my example on AW.net very carefully. Once FindPort() returns with the port, the Forbid() state has ALREADY been restored, even if it was broken waiting for a semaphore. The breaking/restarting would have happened BEFORE the list was searched for the port. Nothing could have obtained the semaphore since FindPort() released it, since no other task would have been scheduled to call ObtainSysList().

The example you just gave would still work fine.
OS4 design for ObtainSysList/ReleaseSysList : Comment 20 of 114ANN.lu
Posted by Thomas Frieden on 11-Jul-2004 21:02 GMT
Great, little troll, if you would have read on, you would have known that the function does not exist. It was planned to implement something like this, but it was rejected. The only trace left is the example code in the autodoc, which was admittedly overlooked.

Additionally, it's hillarious to call this a "design fault". A design fault in the system would be something that would be impossible to get out. This is not even in there.

So, little troll, instead of babbling some nonsense you read somewhere, get a clue (and a life), and check your information before flaming.
OS4 design for ObtainSysList/ReleaseSysList : Comment 21 of 114ANN.lu
Posted by Thomas Frieden on 11-Jul-2004 21:04 GMT
In reply to Comment 4 (Fabio Alemagna):
Fabio, it's not even there, so there is no autodoc for this function.
OS4 design for ObtainSysList/ReleaseSysList : Comment 22 of 114ANN.lu
Posted by Fabio Alemagna on 11-Jul-2004 21:04 GMT
In reply to Comment 18 (Fabio Alemagna):
> Mmmh, yeah, that's true. So it appears I have to put it forth again :-).

Mmmh... no, it's not true, actually. 68k's FindPort() would be blocked until the other task released the semaphore, and even if the other task deleted the port, FindPort() would then not... find the port, which then would not make PutMsg() be called.

Damned, perhaps I should go to bed.
OS4 design for ObtainSysList/ReleaseSysList : Comment 23 of 114ANN.lu
Posted by Peter Gordon on 11-Jul-2004 21:04 GMT
In reply to Comment 20 (Thomas Frieden):
Well there you go... it has been rejected anyway.

It was only mentioned in the Autodoc in the description of another function. There wasn't even a placeholder for their own descriptions.

I guess people should get the facts first ;) It is unfortunate that the reference was left in.
OS4 design for ObtainSysList/ReleaseSysList : Comment 24 of 114ANN.lu
Posted by Fabio Alemagna on 11-Jul-2004 21:11 GMT
In reply to Comment 20 (Thomas Frieden):
> It was planned to implement something like this, but it was rejected.

Oh dear, I knew there was something strange going on here... Me agreeing with an AOS4 design decision? Naaaah...

Indeed, no such decision. I'm relieved :-)
OS4 design for ObtainSysList/ReleaseSysList : Comment 25 of 114ANN.lu
Posted by Johan Rönnblom on 11-Jul-2004 21:12 GMT
In reply to Comment 20 (Thomas Frieden):
Hey! He's asking a polite question. He wants you to answer. No need to
be so hostile/defensive about it, just give him the info he wants, ok?

Ok, this idea was flawed, so you rejected it. End of story,
everything's fine.
OS4 design for ObtainSysList/ReleaseSysList : Comment 26 of 114ANN.lu
Posted by Peter Gordon on 11-Jul-2004 21:24 GMT
In reply to Comment 24 (Fabio Alemagna):
Actually Fabio, it sounds like THEY agree with YOU... quoting Hans-Joerg from AW.net:

"The idea is to retire the lists in execbase and replace them with dummy data. The real lists will go somewhere else. The major point is to get away from Forbid()."

Which is the same your "superior" suggestion anyway, no? ;-)
OS4 design for ObtainSysList/ReleaseSysList : Comment 27 of 114ANN.lu
Posted by adesigner on 11-Jul-2004 21:25 GMT
In reply to Comment 20 (Thomas Frieden):
Ok, thank you.

This bit still puzzles me though:
"This doesn't necessarily pose a problem. 68k and PPC use different jump tables, so the 68k jump table could use a different implementation of FindPort, and the FindPort implementation can actually check if it is in forbid state and not use the semaphore in this case."

I would love to hear how that should work.

I mean if Task A calls function with Forbid(), and Task B in semaphore lock:

- Task B obtains the lock (semaphore) and calls FindPort. No port is found (NULL). Rescheduling occurs.
- Task A gets to run, Forbids and then calls FindPort. Task A will not use semaphore locking due to Forbid state. No port is found (NULL).
- Task A completes the business (say AddPort), and Permit
- task B get to run, and happily thinks port is not there, and AddPort again.
-> Two ports with same name.

How doesn't this pose a problem?
OS4 design for ObtainSysList/ReleaseSysList : Comment 28 of 114ANN.lu
Posted by Peter Gordon on 11-Jul-2004 21:34 GMT
In reply to Comment 27 (adesigner):
No doubt if it had been implemented, my suggestion of looking to see if the calling task has obtained the semaphore, maybe using a private flag, and if not, obtaining it internally would solve this.

Task A would go into a wait state INSIDE FindPort() (breaking the Forbid() condition) until Task B released the semaphore, then FindPort would look in the list and find the port Task A added. Problem solved.
OS4 design for ObtainSysList/ReleaseSysList : Comment 29 of 114ANN.lu
Posted by Fabio Alemagna on 11-Jul-2004 21:36 GMT
In reply to Comment 27 (adesigner):
> Task A will not use semaphore locking due to Forbid state

That's where the reasoning fails: Task A will use semaphore locking, albeit shortly, inside the 68k version of the FindPort() function.
OS4 design for ObtainSysList/ReleaseSysList : Comment 30 of 114ANN.lu
Posted by adesigner on 11-Jul-2004 21:39 GMT
In reply to Comment 28 (Peter Gordon):
"Task A would go into a wait state INSIDE FindPort() (breaking the Forbid() condition) until Task B released the semaphore, then FindPort would look in the list and find the port Task A added. Problem solved."

And what if Task A had some other critical (read: requiring Forbid) initialization within the same Forbid/Permit block?
OS4 design for ObtainSysList/ReleaseSysList : Comment 31 of 114ANN.lu
Posted by Peter Gordon on 11-Jul-2004 21:43 GMT
In reply to Comment 29 (Fabio Alemagna):
OK... as we're debating a hypothetical situation coming from a now moot point, i'll continue to join in, too.

Just supposing you were implementing this method and wanted it work even with PPC programs that use the Forbid() method, you could do this instead:

* Have a private field in the task structure with a mask of bits for obtained lists
* Have ObtainSysList()/ReleaseSysList() maintain that mask automatically
* Make FindPort()/AddPort()/RemPort() check these bits and obtain the semaphores temporarily if not already obtained.

Voila, a legacy supporting system that could be phased out. The only problem i could see is with RemPort():

Forbid()
RemPort( blahport )
Permit()

Of course... RemPort() could now break Forbid() due to obtaining the semaphore, and another task could put a message on the port. There should be a way around that, though.

Mind you... its all moot now anyway ;)
OS4 design for ObtainSysList/ReleaseSysList : Comment 32 of 114ANN.lu
Posted by Peter Gordon on 11-Jul-2004 21:44 GMT
In reply to Comment 30 (adesigner):
Well, then its probably a badly written program ;-) I seriously doubt you'd break all that much software with that.
OS4 design for ObtainSysList/ReleaseSysList : Comment 33 of 114ANN.lu
Posted by Peter Gordon on 11-Jul-2004 21:47 GMT
In reply to Comment 31 (Peter Gordon):
Of course that other task adding the message would have to be the task already that either obtained the list, or was ahead in the queue for it. Its pretty unlikely, but not *impossible*.
OS4 design for ObtainSysList/ReleaseSysList : Comment 34 of 114ANN.lu
Posted by adesigner on 11-Jul-2004 21:51 GMT
In reply to Comment 32 (Peter Gordon):
Any program adding two ports inside same Forbid/Permit pair. Quite common with apps that have ARexx port in addition to some other public port.

Or AddPort + AddSemaphore for example.

Since Forbid/Permit is so discouraged, programmers typically try to reduce the number of calls by grouping as much stuff within the pair as possible.

It would break existing apps. But as this is 100% theoretical it doesn't really matter.

IMO my original statement is still valid, though: you can't mix Forbid/Semaphore locking.
OS4 design for ObtainSysList/ReleaseSysList : Comment 35 of 114ANN.lu
Posted by Peter Gordon on 11-Jul-2004 21:57 GMT
In reply to Comment 34 (adesigner):
> Any program adding two ports inside same Forbid/Permit pair.

I don't see this is a problem. If you want to add two unique ports:

Forbid()
if( !FindPort( port1 ) ) .. allocate and addport port1
if( !FindPort( port2 ) ) .. allocate and addport port2
Permit()

The only time the Forbid() state will be broken is BEFORE the first FindPort scans the list. Think about it:

* FindPort() calls ObtainSysList(), and the task goes into a waitstate
* ObtainSysList() returns, and the system is in Forbid again
* FindPort finishes, and calls ReleaseSysList()

No other task will be scheduled until the Permit, so no further ObtainSysList calls from this task will break the Forbid() condition.
OS4 design for ObtainSysList/ReleaseSysList : Comment 36 of 114ANN.lu
Posted by adesigner on 11-Jul-2004 22:03 GMT
In reply to Comment 35 (Peter Gordon):
And if the code was:

Forbid();
p1 = FindPort( port1 );
p2 = FindPort( port2 );
if( !p1 ) .. allocate and addport port1
if( !p2 ) .. allocate and addport port2
Permit();

Getting what I'm after? (hint: a classic race condition, much like ObtainSemaphoreList without higher level lock)
OS4 design for ObtainSysList/ReleaseSysList : Comment 37 of 114ANN.lu
Posted by Peter Gordon on 11-Jul-2004 22:05 GMT
In reply to Comment 34 (adesigner):
Oh wait.. or are you thinking that breaking the Forbid() because of a Wait() is permanent?

That couldn't possibly work because Permit() calls must match Forbid() calls. If Wait() broke Forbid() on a permanent basis, tracking it would be a nightmare. Your task would have to know for sure if it had EVER been in a wait condition since the Forbid(), which is impossible since system calls are supposed to be a black box, for example.

To quote the autodocs:
"The current task will not be rescheduled as long as it is ready to
run. In the event that the current task enters a wait state, other
tasks may be scheduled. Upon return from the wait state, the original
task will continue to run without disturbing the Forbid()."
OS4 design for ObtainSysList/ReleaseSysList : Comment 38 of 114ANN.lu
Posted by Peter Gordon on 11-Jul-2004 22:05 GMT
In reply to Comment 36 (adesigner):
That would STILL work.
OS4 design for ObtainSysList/ReleaseSysList : Comment 39 of 114ANN.lu
Posted by Peter Gordon on 11-Jul-2004 22:09 GMT
In reply to Comment 38 (Peter Gordon):
The only time your method would cause a problem would be if it was accessing two seperate system lists, like:

Forbid()
port = FindPort( blah );
blah = FindSomethingElseThatRequiresADifferentSemaphore();
if( !port ) ... allocate and add port
if( !blah ) ... allocate and add blah
Permit()

Since now there are two places the Forbid() can be broken.
OS4 design for ObtainSysList/ReleaseSysList : Comment 40 of 114ANN.lu
Posted by adesigner on 11-Jul-2004 22:31 GMT
In reply to Comment 38 (Peter Gordon):
Ah yes, it'd indeed work for same semaphore. The problem is still some other atomic stuff, plus the RemPort and similar issues.
OS4 design for ObtainSysList/ReleaseSysList : Comment 41 of 114ANN.lu
Posted by itix on 11-Jul-2004 23:00 GMT
In reply to Comment 39 (Peter Gordon):
What if multiple semaphores are obtained? For example: Task A: ObtainSysList(OSL_PORTLIST);ObtainSysList(OSL_TASKLIST); Task B: ObtainSysList(OSL_TASKLIST);ObtainSysList(OSL_PORTLIST); ? Task A got port list and Task B got task list... now they cant proceed anymore and system hangs sooner than later.
OS4 design for ObtainSysList/ReleaseSysList : Comment 42 of 114ANN.lu
Posted by Stefan Burström on 11-Jul-2004 23:07 GMT
In reply to Comment 41 (itix):
>What if multiple semaphores are obtained? For example:

This is the classic dinning philosophers dilema. Get any computer science
book on real time programming and you will find the solution to this problem.

rgds,
Stefan
OS4 design for ObtainSysList/ReleaseSysList : Comment 43 of 114ANN.lu
Posted by Amon_Re on 12-Jul-2004 03:34 GMT
In reply to Comment 15 (Johan Rönnblom):
You are right, i was being overly agitated by it, and fatigue clouded my judgement, so yea, i was being paranoïde i guess
OS4 design for ObtainSysList/ReleaseSysList : Comment 44 of 114ANN.lu
Posted by Peter Gordon on 12-Jul-2004 06:15 GMT
In reply to Comment 41 (itix):
I dunno... maybe in the AutoDocs they'd state "WARNING: Only obtain one system list at a time" or something. Doesn't really matter now.
OS4 design for ObtainSysList/ReleaseSysList : Comment 45 of 114ANN.lu
Posted by Georg Steger on 12-Jul-2004 07:41 GMT
In reply to Comment 39 (Peter Gordon):
> The only time your method would cause a problem would be if it was accessing
> two seperate system lists, like:
...
>Since now there are two places the Forbid() can be broken

No, it can also happen when just one semaphore is involved and a function obtaining that semaphore is called twice while in Forbid() state. Then Forbid state might be broken twice. Example:

Forbid();
if (!FindPort("bla"))
{
AddPort("bla");
}
Permit();

Both FindPort and AddPort would use same portlist semaphore. That FindPort can
break Forbid state we already now. But also AddPort() call can break it another
time. And that's why:

- when FindPort() breaks Forbid() state not just THISTASK may endup in the
semaphore_wait_queue, other tasks as well may end up there. In the time
while the actual owner of the semaphore is still holding it, ie. before it
releases it.

- when THISTASK obtains the semaphore and then releases it again at end of
FindPort() the semaphore ownership may be handed over to the next one in
the semaphore wait queue. Yes, we are still in Forbid state so that other
task won't get to run immediately. Not before we call Permit. But still the
semaphore no longer is free or belongs to THISTASK.

- so the following AddPort() which locks the semaphore too, might not be able
to acquire it immediately -> Forbid state broken -> anything can happen ->
like the port we tried to FindPort() can be created by someone else, although
FindPort() initially reported that there's no such port at the moment in the
port list.
OS4 design for ObtainSysList/ReleaseSysList : Comment 46 of 114ANN.lu
Posted by Peter Gordon on 12-Jul-2004 08:12 GMT
In reply to Comment 45 (Georg Steger):
Yep, granted, you're quite correct this could happen. The idea was flawed. This is probably why it was abandoned.
OS4 design for ObtainSysList/ReleaseSysList : Comment 47 of 114ANN.lu
Posted by Fabio Alemagna on 12-Jul-2004 08:27 GMT
In reply to Comment 45 (Georg Steger):
> so the following AddPort() which locks the semaphore too,

but AddPort wouldn't use the semaphore, why should it?
OS4 design for ObtainSysList/ReleaseSysList : Comment 48 of 114ANN.lu
Posted by Peter Gordon on 12-Jul-2004 08:56 GMT
In reply to Comment 47 (Fabio Alemagna):
Because its modifying a publically accessibly linked list. Its possible for a task to be rescheduled while in the middle of modifying the list. Another task then comes along, doesn't use the semaphore, and could only see some of the items, or follow a wrong pointer or whatever, depending on what the other task was doing.
OS4 design for ObtainSysList/ReleaseSysList : Comment 49 of 114ANN.lu
Posted by DET Nicolas on 12-Jul-2004 09:19 GMT
In reply to Comment 20 (Thomas Frieden):
Well, there is no troll here.

Just discussion about AmigaOS API. Moreover, the news text says clearly that this "extention" has been rejetected.
What's wrong in giving some polite critics anyway ?

Bye
OS4 design for ObtainSysList/ReleaseSysList : Comment 50 of 114ANN.lu
Posted by DET Nicolas on 12-Jul-2004 09:19 GMT
In reply to Comment 20 (Thomas Frieden):
Well, there is no troll here.

Just discussion about AmigaOS API. Moreover, the news text says clearly that this "extention" has been rejetected.
What's wrong in giving some polite critics anyway ?

Bye
Anonymous, there are 114 items in your selection [1 - 50] [51 - 100] [101 - 114]
Back to Top