sis-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Martin Desruisseaux (Jira)" <j...@apache.org>
Subject [jira] [Updated] (SIS-487) Define a synchronization policy for WritableRenderedImage
Date Wed, 08 Jan 2020 10:50:00 GMT

     [ 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)

Mime
View raw message