On 13.12.23 15:27, Kinsey Moore wrote:
On Wed, Dec 13, 2023 at 12:26 AM Sebastian Huber
<sebastian.hu...@embedded-brains.de
<mailto:sebastian.hu...@embedded-brains.de>> wrote:
On 09.12.23 03:31, Kinsey Moore wrote:
> The inode cache can be altered and queried by multiple threads of
> execution, even before the introduction of delayed write support for
> NAND. This provides a new lock to prevent simultaneous
modification of
> the cache.
Under which condition is the inode cache accessed without the file
system instance lock for normal operations (no delayed works stuff)?
Your new code still has no test cases and the configuration option is
not documented (http://devel.rtems.org/ticket/4961
<http://devel.rtems.org/ticket/4961>).
I am still in favour of an alternative locking approach:
1. The delayed work support uses a mutex D and a condition variable C
used with D.
2. Add a queue for the delayed work to the fs information and a node to
register the info in the delayed work support.
3. The first delayed work request of a JFFS2 instance registers the fs
information in the delayed work support and uses C to signal the
work to
the delayed work task.
4. Further requests just get enqueued and signaled using D and C.
5. When a instance is unmounted, drain the delayed work queue using
D and C.
The delayed work uses the fs info mutex to protect the work. You need
also reference count for the fs info to control the work and the drain
during unmount.
Using the FS information lock at the level of delayed work callback
isn't workable with the current API exposed/consumed by the JFFS2
library as this information is not exposed to the thread calling the
delayed work without modification of the JFFS2 library itself or abusing
macros to pull in information that isn't actually provided to them (and
would require that local variable naming be extremely consistent across
usages of this abusive macro).All that is available is the callback
function pointer and an opaque void pointer argument.
I don't understand the problem. If you need JFFS2 specific details, why
don't you implement this part to the JFFS2 area?
Other
implementations that use this library achieve safe locking without the
FS information lock.
What is "this library"?
Before you started with adding some locks here and some locks there, the
complete JFFS2 state was protected by a single instance lock. This is
not great in terms of SMP performance, however, it is very simple and it
works. I don't know why you can't get the instance lock, do the delayed
work, and then release the instance lock.
--
embedded brains GmbH & Co. KG
Herr Sebastian HUBER
Dornierstr. 4
82178 Puchheim
Germany
email: sebastian.hu...@embedded-brains.de
phone: +49-89-18 94 741 - 16
fax: +49-89-18 94 741 - 08
Registergericht: Amtsgericht München
Registernummer: HRB 157899
Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler
Unsere Datenschutzerklärung finden Sie hier:
https://embedded-brains.de/datenschutzerklaerung/
_______________________________________________
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
