If task 1 will have only one connection to customer.db and task 2 will
have only one connection to fault.db then it looks like you don't need
any locking indeed. And most part of mutexes is not necessary too,
although probably you'll need ones that protect some global variables
(can't say how many of these is there).

Pavel

On Mon, Mar 22, 2010 at 8:09 AM, GeoffW <geoffw...@hotmail.com> wrote:
>
> Hello
>
> I am still working away at this porting exercise, I have a couple of general
> questions please that I would value some comments on.
>
> The absence of a file locking mechanism in MQX means the best I can do is a
> "dot lock" type locking strategy. I have implemented this now, but what is
> concerning me is the amount of extra file opening and closing it is creating
> in addition to the actual accessing of the database. In my embedded system I
> am using NOR flash which has a limited write cycle life. I dont really have
> a good feel as to what amount of extra flash write overhead I am causing, is
> there an easy way to roughly estimate this ?
>
> If this really is an issue then I have no option other than to have no file
> locking. This might be acceptable in our typical application, I just need to
> make sure I understand the limitations.
>
> Lets say for the sake of an example, I have an Application made up of 10
> tasks. Task 1 and only task 1 can access a customer.db database file. Task 2
> and only task 2 can access say a fault logging database fault.db.
>
> Are these 2 statement correct for the above situation ?
>
> 1) This will work fine with no file locking.
>
> 2) I must make sure that I have implemented the mutex system to allow me to
> define SQLITE_THREADSAFE.
>
> Just wanted to sanity check my understanding of the concepts here.
>
> Thanks Geoff
>
>
>
>
>
>
>
>
>
> --
> View this message in context: 
> http://old.nabble.com/Porting-Sqlite-to-MQX-OS%3A-Question-3-tp27985475p27985475.html
> Sent from the SQLite mailing list archive at Nabble.com.
>
> _______________________________________________
> sqlite-users mailing list
> sqlite-users@sqlite.org
> http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
>
_______________________________________________
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users

Reply via email to