This is the mail archive of the ecos-discuss@sources.redhat.com mailing list for the eCos project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

spin locks


Andre Asselin writes:



> Nick Garnett writes:

> > > I was looking at the new cyg_spinlock stuff in the kernel, and
noticed that
> > > the uniprocessor version of the functions don't disable scheduling or
block
> > > DSRs when a lock is acquired.  In order for spinlocks to be useful,
they
> > > need to be able to lock between DSRs and "thread" level code (think
of a
> > > producer/consumer model for example).  On a uniprocessor machine,
that
> > > means the scheduler and DSR dispatching need to be disabled while any
lock
> > > is acquired.  On an MP machine, scheduling and DSR dispatching would
be
> > > disabled on the CPU that acquires the spinlock, and other CPUs would
use
> > > the spin mechanics to synchronize against the CPU that owns the lock.

> > To keep things simple I took the approach that the basic spinlock
> > would not make any statement about safety with respect to interrupts
> > and DSRs. It only functions to provide synchronization between
> > CPUs.

> > If the user needs interrupt-safety he can use the *_intsave()
> > variants, which blocks all local preemption. I guess there could also
> > be *_schedlock() variants that would behave as you suggest. But given
> > the relative cost of the scheduler lock mentioned above, and the
> > intention that the spinlocks should only be held for very brief
> > lengths of time, this did not seen necessary. Also, the scheduler lock
> > is global to all CPUs, since it protects shared data, and so is less
> > useful for very low level synchronization purposes.

> I definitely vote for adding a *_schedlock() varient to spinlocks.  Like
I
> said above, if you are synchronizing between thread level code and DSR
code,
> you have to have that kind of functionality.  I think it would be a
better design
> if these kind of functions are provided by the OS instead of user code
doing a
> schedule lock followed by a spinlock acquisition because I'd be afraid of
> running into race conditions.  I think the *_schedlock() functions would
also
> be more future proof if details of SMP / scheduling / DSRs, etc. change
(such
> as if the scheduler lock were changed to be per CPU instead of per
system).

Nick,

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.

Andre Asselin
IBM ServeRAID Software Development
Research Triangle Park, NC




Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]