Re: [ECOS] atomic singly linked lists

[Nick Garnett <nickg at redhat dot com>]

"Andre Asselin" <asselin@us.ibm.com> writes:

> 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.

But the *_intsave() variants have the same effect, and are much
cheaper. Alternatively, using the scheduler lock alone will also have
the same effect.

> 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.

In general the scheduler lock alone is adequate.

Another point to consider is that by having spinlocks that also lock
the scheduler will break the conceptual layering of the
system. Synchronization is built out of layered mecanisms. At the
bottom are fast but global mechanisms like interrupt disables and
spinlocks. In the middle is the scheduler lock and at the top are
synchronization objects like mutexes and semaphores. Each layer is
built on the layer below. 

> 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).

That is unlikely to happen, it would be a major rewrite of the kernel.


> I agree that adding a priority mechanism to DSRs would not be a good
> thing to do, and I don't advocate that.  I think, though, that you
> can make them a general purpose mechanism and have them be very
> useful without adding priority stuff.  I'll bring up NT again: DPCs
> in NT have no documented priority mechanism, and even with that
> restriction, they are useful (in fairness, there is an undocumented
> way to queue a DPC at the head of the DPC queue as opposed to the
> tail of the queue, but its almost never used).  I personally have
> been able to get much better performance out of an SMP system by
> making use of DPCs (on a uni system, there's no benefit, but for an
> SMP system, it can pay off).  Trying to do the same thing by using
> threads and the context switch overhead it implies wouldn't have
> worked.  Hopefully you might reconsider your decision?

Separating the DSRs from the interrupt system would be another major
rewrite. Also bear in mind that eCos is meant to be a small, embedded
kernel, not a big general purpose system like NT. We achieve this by
not making every facility as general purpose as it can be. Otherwise
we would end up with something as gross and inefficient as NT. DSRs
are really just a mechanism for solving a problem in ISR->thread
synchronization, nothing more.


-- 
Nick Garnett, eCos Kernel Architect
Red Hat, Cambridge, UK