Messages in this thread | | | Date | Mon, 25 Jan 1999 21:42:41 +0100 (CET) | From | Andrea Arcangeli <> | Subject | Re: down_interruptible and timers |
| |
On Mon, 25 Jan 1999, MOLNAR Ingo wrote:
> Fourth, being able to initialize dynamic variables is not 'just' a > performance optimization, it's a requirement.
Ingo what are you smoking???
You _can_ initialze a dynamic variable at runtime using:
sem = MUTEX;
or sem = MUTEX_UNLOCKED;
I _don't_ need sema_init(). You can remove sema_init() and I'll run _fine_ using MUTEX and MUTEX_LOCKED instead. In 2.2.0-pre9 sema_init() when it's used, it's used _only_ as a performance optimization because the code where it's used knows _how_ sema_init() works and __just__ depends on semaphore internals, it knows that all other fields of the semaphore has to be zero (and are just zero by the memset(dst, 0, sizeof(struct)) done a bit before) and set the only thing that need to be 1 to 1.
My patch only want to not hurt performances but avoiding other developers to get mistakes using sema_init() thinking that it's a sane semaphore initializer, while instead is only a trick to set to 1 only a field in a long just zeroed struct.
My patch is _sure_ not worse than 2.2.0-pre9 with the differences that there won't be further mistakes for _sure_. The policy is, if you want to do tricky things to handle performances, do it by hand instead of simulate to do clean things while instead they are still tricky.
Maybe I am wrong but I assure you that this is exactly what I understood so far about sema_init() reading it and where it's used. Please tell me if I am missing something. Excuse me if I caused waste of time to you.
Andrea Arcangeli
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/
| |