[haiku-gsoc] Re: XSI semaphore implamentation patch #2
- From: Ingo Weinhold <ingo_weinhold@xxxxxx>
- To: haiku-gsoc@xxxxxxxxxxxxx
- Date: Tue, 29 Jul 2008 15:47:23 +0200
On 2008-07-29 at 00:24:29 [+0200], Salvatore Benedetto <emitrax@xxxxxxxxx>
wrote:
>
> attached is a second patch of xsi semaphore implementation.
> It includes the SEM_UNDO features.
>
> I actually spent more time than I though on this one, because
> the sem_undo list get accesed not only when a process exit,
> thus executing all its sem_undo request, but also when calling
> semctl with SETVAL or SETALL on a semaphore (all sem_undo request
> must be cleared, that is deleted).
>
> I reworked it three times in order to keep it as simple as possible
> and eventually came up with a single global sem_undo list (sUndoList).
> I wanted to add as little as possible to the team structure.
>
> The complexity of the algorithm when removing an element is of course O(n)
As are xsi_sem_undo() and IPC_RMID (or would be, if it removed the undo
values).
> as I iterated through the list but only a simple short value has been
> to the team
> structure (at first it was a boolean value) and speed shouldn't really
> be a problem
> as I think we won't have many semaphores in the systems.
Er, and you didn't wonder whether trading performance for a few bytes per
team that uses XSI semaphores might not be the best idea?
> Anyway, if it happens to be a problem, I'll try with another solution.
Well, I proposed one that doesn't have the performance issues. I wonder why
you even asked.
> The code has been tested with bonnie++, which uses the SEM_UNDO feature, and
> it seems to works fine.
>
> I've also fixed some bugs that weren't easy to discover by simple
> reviewing the code
> in the first patch and bonnie++ helped with this. In fact it now runs
> in multiprocesses mode.
Very nice. I hope the insight that code review won't uproot all bugs
encourages you to actually write unit tests.
CU, Ingo
Other related posts:
