This is the mail archive of the
ecos-discuss@sources.redhat.com
mailing list for the eCos project.
Re: spin locks
- To: "Andre Asselin" <asselin at us dot ibm dot com>
- Subject: [ECOS] Re: spin locks
- From: Nick Garnett <nickg at redhat dot com>
- Date: 17 Sep 2001 14:36:00 +0100
- Cc: ecos-discuss at sources dot redhat dot com
- References: <OF2DFA1E17.60E8ADFA-ON85256AC7.006FD7C6@raleigh.ibm.com>
"Andre Asselin" <asselin@us.ibm.com> writes:
> I was thinking about this some more, and realized that the *_schedlock()
> versions of these routines are necessary for thread vs thread locking as
> well as thread vs DPC locking. If you don't disable scheduling when you
> acquire a spinlock, that CPU can be rescheduled to another thread, and if
> the new thread also tries to acquire the same spinlock, it'll result in a
> deadlock. Therefore, the current spinlock implementation is only useful
> for contexts where you can guarantee that scheduling has already been
> disabled, such as from within an interrupt or DSR.
>
This is true. Threads should really use higher level mechanisms such
as mutexes for synchronization. If these prove too expensive then the
*_intsave() spinlock functions should be used.
Compared with spinlocks, the scheduler lock is a very expensive
mechanism. I am not at all happy about mixing things with such
major differences in behaviour in a single primitive.
--
Nick Garnett, eCos Kernel Architect
Red Hat, Cambridge, UK