Re: Guarantee Critical Regions in Portable code. Portable Semaphores?

It is not the business of the application layer to interfere with the
system activities. Disabling interrupts is the kernel level operation.

The whole point is that it gets implemented inside the OS level. Obviously
for standalone single-threaded applications there's no problem. FullFAT is
below the application level, and provides an application level interface.


You should not make any assumptions about the atomicity of any operation

unless you know the target hardware and software in the very detail.
There are the OS services which you should rely upon.

I'm not making assumptions about how to ensure an atomic operation on
another platform. (Because I cannot!) I provide 2 functions, and inside
them I ask the developer to do whatever is necessary to enter a critical
region, to ensure atomic operations. Then to leave that state when the
second function is called. By calling the appropriate OS services.

It's true that DMA and other peripherals on the core could be running.

Operating systems provide sync functions, to remove the cache problem. So
if a developer places sync functions inside my critical region functions,
then all should work.

VDK is junk. Being dissatisfied with VDK and ucLinux, I rolled my own OS

for BlackFin.

We also wrote an operating system for BlackFIN, (well the firm I work
for).

How can the FAT driver know when it is safe to disable the interrupts
and for how long it is safe to disable the interrupts? That is very
application and platform dependent, and it is not the business of the
driver to make any assumptions.

You cannot know it's safe for sure, but a single increment or decrement
instruction shouldn't take a dangerous amount of time. It's unlikely you'll
be using a FAT driver in a critical system.

I guess the best thing to do is protect critical memory attributes with an
OS provided semaphore.

I just need to find the best way to make a semaphore wrapper, that can be
easily ported to other operating systems.

Drop the project.

I won't take your advice, but thanks for helping me to think about the
problems from a different angle!

I've also decided that LFN support will be built dependent on the
configuration file. So LFN support will work like a module, either you use
it or you don't.

From VDK it provides a function to CreateSemaphore,PendSemaphore,
ReleaseSemaphore. Do most OS's essentially expose the same interfaces? If
so what kind of objects do they return?

James





james.walmsley wrote:

It's not a naive idea, its just challenging. Of course there are
issues
when porting anything. However you can design code to be portable, and
make
any porting easier for the end developer.
Can you explain why on a single core system why you think that
disabling
interrupts



won't guarantee atomic operations,

Because there is cache, DMA, speculative execution and deferred
reads/writes.

and also explain why you think it is bad.

You should not make any assumptions about the atomicity of any operation

unless you know the target hardware and software in the very detail.
There are the OS services which you should rely upon.

Working on BlackFIN, disabling interrupts means that the VDK Os
scheduler
simply cannot switch threads/processes because as with all OS's this
requires a timer interrupt.

VDK is junk. Being dissatisfied with VDK and ucLinux, I rolled my own OS

for BlackFin.

Obviously disabling interrupts is bad if done over to long a period of
time. It is sometimes necessary I believe, and if you fully understand
when
to do it and how then its ok. Essentially it should only be done over
a
very short period of time.

How can the FAT driver know when it is safe to disable the interrupts
and for how long it is safe to disable the interrupts? That is very
application and platform dependent, and it is not the business of the
driver to make any assumptions.

On a single-core system, if disabling interrupts prevents the OS from
task
switching, this should mean that all operations are atomic.

Disabling interrupts doesn't imply atomicity, because there is cache,
DMA, speculative execution and deferred reads/writes.

If that is the
case, a simple mutex lock system should implementable?

Only if it based on the services provided by target OS.

I don't know the answers, I just want your opinions, and your
explanations.

Drop the project.


Vladimir Vassilevsky
DSP and Mixed Signal Design Consultant
http://www.abvolt.com


.

Relevant Pages

  • Re: sony vaio pcg-gr390
    ... PCI-Only Interrupts: none ... Location Bus Device Pin Link IRQs ... penalty: 1050 ... isa_probe_children: disabling PnP devices ...
    (freebsd-current)
  • Re: [RFC/PATCH] Kdump: Disabling PCI interrupts in capture kernel
    ... I know very little about consoles and their working. ... >> console driver needed interrupts to be enabled at the controller. ... looking at disabling the DMA from the devices. ... interrupt disable bit in PCI-PCI bridge is optional and if implemented, ...
    (Linux-Kernel)
  • Re: [RFC] mmiotrace full patch, preview 1
    ... the "first" probe gets selected and executed. ... kmmio_handler, where-ever it was triggered, executes with interrupts ... enable single-stepping. ... or does disabling interrupts guarantee that? ...
    (Linux-Kernel)
  • Re: IIgs Debuggers?
    ... Are you directly disabling any interrupts? ... I do disable interrupts on the initial loading of the wavebank into the DOC RAM, but I do so *exactly* as you have mentioned. ... I deliberately chose MIDI Synth sequences that all share the same instruments and wavebank file - thereby eliminating the need to reload them. ...
    (comp.sys.apple2.programmer)
  • Re: CFQ + 2.6.13-rc4-RT-V0.7.52-02 = BUG: scheduling with irqs disabled
    ... which should all have stopped by the time we execute do_exit. ... interrupts. ... I cannot even convince myself that it is currently safe right ... send the line "unsubscribe linux-kernel" in ...
    (Linux-Kernel)