[
https://issues.apache.org/jira/browse/SIS-487?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Martin Desruisseaux updated SIS-487:
------------------------------------
Description:
Apache SIS 1.1 provides a {{ComputedImage}} class which manages automatically
the synchronization locks for {{computeTile(tileX, tileY)}} invocations.
However we currently have no synchronization mechanism if users invoke
{{getWritableTile(tileX, tileY)}} method and writes themselves in the image
(outside {{computeTile(tileX, tileY)}} method).
We could easily use {{ReentrantLock}} in {{getWritableTile(…)}} /
{{releaseWritableTile(…)}} methods since those two methods shall be invoked in
pairs. But this lock would not be fully effective, because we would also need
to acquire/release lock in {{getTile(…)}} method (for read-only raster) but
have no easy way of doing that. The problem is that there is no
{{releaseTile(…)}} method for raster acquired in read-only mode.
Some possible actions are:
* *Copy-on-write strategy:* {{getWritableTile(…)}} returns a _copy_ of the tile
and that copy replaces the original tile when {{releaseWritableTile(…)}} is
invoked. Inconvenient is that this strategy may have signification performance
and memory impact because of potentially large amount of copy operations.
* *User responsibility:* Provides a {{ReadWriteLock}} per image and let users
do the synchronization themselves.
An advantage of the _user responsibility_ approach is that we could use a
single {{ReadWriteLock}} for the whole image. It would allow image-wide
consistency when a write operation may require writing in more than one tile.
By contrast the _copy-on-write_ strategy would not ensure such image-wide
consistency since it would be done on a tile-by-tile basis only.
was:
Apache SIS 1.1 provides a {{ComputedImage}} class which manages automatically
the synchronization locks for {{computeTile(tileX, tileY)}} invocations.
However we currently have no synchronization mechanism if users invoke
{{getWritableTile(tileX, tileY)}} method and writes themselves in the image
(outside {{computeTile(tileX, tileY)}} method).
We could easily use {{ReentrantLock}} in {{getWritableTile(…)}} /
{{releaseWritableTile(…)}} methods since those two methods shall be invoked in
pairs. But this lock would not be fully effective, because we would also need
to acquire/release lock in {{getTile(…)}} method (for read-only raster) but
have no easy way of doing that. The problem is that there is no
{{releaseTile(…)}} method for raster acquired in read-only mode.
Some possible actions are:
* *Copy-on-write strategy:* {{getWritableTile(…)}} returns a _copy_ of the tile
and that copy replaces the original tile when {{releaseWritableTile(…)}} is
invoked. Inconvenient is that this strategy may have signification performance
and memory impact because of potentially large amount of copy operations.
* *User responsibility:* Provides a {{ReadWriteLock}} per image and let users
do the synchronization themselves.
> Define a synchronization policy for WritableRenderedImage
> ---------------------------------------------------------
>
> Key: SIS-487
> URL: https://issues.apache.org/jira/browse/SIS-487
> Project: Spatial Information Systems
> Issue Type: Task
> Components: Features
> Affects Versions: 1.1
> Reporter: Martin Desruisseaux
> Priority: Major
>
> Apache SIS 1.1 provides a {{ComputedImage}} class which manages automatically
> the synchronization locks for {{computeTile(tileX, tileY)}} invocations.
> However we currently have no synchronization mechanism if users invoke
> {{getWritableTile(tileX, tileY)}} method and writes themselves in the image
> (outside {{computeTile(tileX, tileY)}} method).
> We could easily use {{ReentrantLock}} in {{getWritableTile(…)}} /
> {{releaseWritableTile(…)}} methods since those two methods shall be invoked
> in pairs. But this lock would not be fully effective, because we would also
> need to acquire/release lock in {{getTile(…)}} method (for read-only raster)
> but have no easy way of doing that. The problem is that there is no
> {{releaseTile(…)}} method for raster acquired in read-only mode.
> Some possible actions are:
> * *Copy-on-write strategy:* {{getWritableTile(…)}} returns a _copy_ of the
> tile and that copy replaces the original tile when {{releaseWritableTile(…)}}
> is invoked. Inconvenient is that this strategy may have signification
> performance and memory impact because of potentially large amount of copy
> operations.
> * *User responsibility:* Provides a {{ReadWriteLock}} per image and let users
> do the synchronization themselves.
> An advantage of the _user responsibility_ approach is that we could use a
> single {{ReadWriteLock}} for the whole image. It would allow image-wide
> consistency when a write operation may require writing in more than one tile.
> By contrast the _copy-on-write_ strategy would not ensure such image-wide
> consistency since it would be done on a tile-by-tile basis only.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
