thread safe fat

Hi,
I'm using in a project of mine a free FAT filesystem to manage an sd
card.
Im' using an ATmega64 so I have not too much RAM. I also need to use
an OS to manage different tasks and  can have File system operation
requests from different tasks. Is there any intrinsic free thread safe
implementation of FAT or have to manage that on my own using
semaphores  or other synchronization tools?
The problem is that if task1 execs a fileopen, filewrite, fileclose
sequence and task2 exec a fopen in the middle of the previous sequence
is quite likely that tha internal data buffers of the FAT module
become corrupted.

Thanks

On Aug 30, 8:54 am, kmag...@gmail.com wrote:

> is quite likely that tha internal data buffers of the FAT module
> become corrupted.

I designed my DOSFS to be reentrant. http://www.zws.com/products/dosfs

On 30 Ago, 15:09, larwe <zwsdot...@gmail.com> wrote:
> On Aug 30, 8:54 am, kmag...@gmail.com wrote:
>
> > is quite likely that tha internal data buffers of the FAT module
> > become corrupted.
>
> I designed my DOSFS to be reentrant.http://www.zws.com/products/dosfs

It seems to be that in your DOSFS each task executing a filewrite or
read has to have at least a block-sized buffer and some file-info
structures as FILEINFO. It's to much expensive for my RAM resources:
with four tasks I run out of memory.

Thanks

On Aug 30, 9:29 am, kmag...@gmail.com wrote:

> It seems to be that in your DOSFS each task executing a filewrite or
> read has to have at least a block-sized buffer and some file-info
> structures as FILEINFO. It's to much expensive for my RAM resources:

The filesystem is designed so that it uses no global RAM. This means
that if RAM is plentiful you get thread-safety free by simply using
separate RAM structures.

If RAM is in short supply, you can use a single set of RAM structures
for an arbitrary number of tasks and provide whatever safing features
you require using your own system of semaphores, exactly as you
requested in your original post.

larwe wrote:

> The filesystem is designed so that it uses no global RAM. This means
> that if RAM is plentiful you get thread-safety free by simply using
> separate RAM structures.

The storage device itself still has to be shared. So is the cache, the 
chain allocation/deallocation algorithms, etc. Anyway there should be 
either semaphores, or client-server mechanism, or a crude disabling of 
the task switching.



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