UIDocument and non-thread-safe Model

  • Hi,

    when using UIDocument, reading and writing the document is done asynchronously in a separate thread. But there's one thing I don't understand: how is that supposed to be used with non-thread-safe models? In my opinion most straight-forward implemented models are _not_ thread-safe.
    If you have the common case of a non-thread-safe model - is there an easy way to let UIDocument do reading/writing synchronously at the main thread? Or are we supposed to serialize every (!) modification of the model in a performAsynchronousFileAccessUsingBlock call?

    Initially reading the document (triggered by openWithCompletionHandler) is usually not a problem. The user can not work with the model before it has been loaded. The problems begin when writing the document: the document write methods are called asynchronously, so the model is accessed at this time, but the user can do things at the same time in parallel through the UI and modify the model at the same time as it is saved - a big source for unpredicted behaviour, data-loss, crashes ...

    The documentation for performAsynchronousFileAccessUsingBlock only mentions accessing the "document" (assuming this means the document's file?). But I think serializing the file access is not enough; accessing the "in-memory" model must also be serialized. Or did I miss something?

    Regards,
    Mani
  • The general idea is that you make some kind of copy of your model's state and pass that as the document's "content", leaving the background free to write it at its leisure.

    On 27 May 2012, at 21:35, Manfred Schwind wrote:

    > Hi,
    >
    > when using UIDocument, reading and writing the document is done asynchronously in a separate thread. But there's one thing I don't understand: how is that supposed to be used with non-thread-safe models? In my opinion most straight-forward implemented models are _not_ thread-safe.
    > If you have the common case of a non-thread-safe model - is there an easy way to let UIDocument do reading/writing synchronously at the main thread? Or are we supposed to serialize every (!) modification of the model in a performAsynchronousFileAccessUsingBlock call?
    >
    > Initially reading the document (triggered by openWithCompletionHandler) is usually not a problem. The user can not work with the model before it has been loaded. The problems begin when writing the document: the document write methods are called asynchronously, so the model is accessed at this time, but the user can do things at the same time in parallel through the UI and modify the model at the same time as it is saved - a big source for unpredicted behaviour, data-loss, crashes ...
    >
    > The documentation for performAsynchronousFileAccessUsingBlock only mentions accessing the "document" (assuming this means the document's file?). But I think serializing the file access is not enough; accessing the "in-memory" model must also be serialized. Or did I miss something?
    >
    > Regards,
    > Mani
  • Yes, in the simple case, you as the client only implement contentsForType: and loadFromContents:error:, which are both main thread hooks and you never need to worry about threading.

    You, the original poster, are correct in your observation that there is no support for a synchronous saving model. This is by design. Applications are encouraged to support iCloud storage, and in an iCloud world, reads and writes can block for indeterminate amounts of time. So, we don't want to encourage anyone to build I/O into the main thread.

    Luke

    On May 27, 2012, at 3:50 PM, "Mike Abdullah" <cocoadev...><mailto:<cocoadev...>> wrote:

    The general idea is that you make some kind of copy of your model's state and pass that as the document's "content", leaving the background free to write it at its leisure.

    On 27 May 2012, at 21:35, Manfred Schwind wrote:

    Hi,

    when using UIDocument, reading and writing the document is done asynchronously in a separate thread. But there's one thing I don't understand: how is that supposed to be used with non-thread-safe models? In my opinion most straight-forward implemented models are _not_ thread-safe.
    If you have the common case of a non-thread-safe model - is there an easy way to let UIDocument do reading/writing synchronously at the main thread? Or are we supposed to serialize every (!) modification of the model in a performAsynchronousFileAccessUsingBlock call?

    Initially reading the document (triggered by openWithCompletionHandler) is usually not a problem. The user can not work with the model before it has been loaded. The problems begin when writing the document: the document write methods are called asynchronously, so the model is accessed at this time, but the user can do things at the same time in parallel through the UI and modify the model at the same time as it is saved - a big source for unpredicted behaviour, data-loss, crashes ...

    The documentation for performAsynchronousFileAccessUsingBlock only mentions accessing the "document" (assuming this means the document's file?). But I think serializing the file access is not enough; accessing the "in-memory" model must also be serialized. Or did I miss something?

    Regards,
    Mani
  • Interesting. When exactly should the copy be made? When subclassing UIDocument the usual methods (writeContents:... or similar) are already called on the separate thread. Can I dispatch making the copy on the main thread with dispatch_sync(dispatch_get_main_queue(), ...) ?
    Is that anywhere discussed in the documentation?

    Mani

    Am 27.05.2012 um 22:49 schrieb Mike Abdullah:

    > The general idea is that you make some kind of copy of your model's state and pass that as the document's "content", leaving the background free to write it at its leisure.
    >
    > On 27 May 2012, at 21:35, Manfred Schwind wrote:
    >
    >> Hi,
    >>
    >> when using UIDocument, reading and writing the document is done asynchronously in a separate thread. But there's one thing I don't understand: how is that supposed to be used with non-thread-safe models? In my opinion most straight-forward implemented models are _not_ thread-safe.
    >> If you have the common case of a non-thread-safe model - is there an easy way to let UIDocument do reading/writing synchronously at the main thread? Or are we supposed to serialize every (!) modification of the model in a performAsynchronousFileAccessUsingBlock call?
    >>
    >> Initially reading the document (triggered by openWithCompletionHandler) is usually not a problem. The user can not work with the model before it has been loaded. The problems begin when writing the document: the document write methods are called asynchronously, so the model is accessed at this time, but the user can do things at the same time in parallel through the UI and modify the model at the same time as it is saved - a big source for unpredicted behaviour, data-loss, crashes ...
    >>
    >> The documentation for performAsynchronousFileAccessUsingBlock only mentions accessing the "document" (assuming this means the document's file?). But I think serializing the file access is not enough; accessing the "in-memory" model must also be serialized. Or did I miss something?
    >>
    >> Regards,
    >> Mani
    >
  • You want to override contentsForType:. That is the main thread hook. This is discussed in http://developer.apple.com/library/ios/DOCUMENTATION/DataManagement/Concept
    ual/DocumentBasedAppPGiOS/Introduction/Introduction.html


    Luke

    On May 27, 2012, at 4:15 PM, "Manfred Schwind" <lists...><mailto:<lists...>> wrote:

    Interesting. When exactly should the copy be made? When subclassing UIDocument the usual methods (writeContents:... or similar) are already called on the separate thread. Can I dispatch making the copy on the main thread with dispatch_sync(dispatch_get_main_queue(), ...) ?
    Is that anywhere discussed in the documentation?

    Mani

    Am 27.05.2012 um 22:49 schrieb Mike Abdullah:

    The general idea is that you make some kind of copy of your model's state and pass that as the document's "content", leaving the background free to write it at its leisure.

    On 27 May 2012, at 21:35, Manfred Schwind wrote:

    Hi,

    when using UIDocument, reading and writing the document is done asynchronously in a separate thread. But there's one thing I don't understand: how is that supposed to be used with non-thread-safe models? In my opinion most straight-forward implemented models are _not_ thread-safe.
    If you have the common case of a non-thread-safe model - is there an easy way to let UIDocument do reading/writing synchronously at the main thread? Or are we supposed to serialize every (!) modification of the model in a performAsynchronousFileAccessUsingBlock call?

    Initially reading the document (triggered by openWithCompletionHandler) is usually not a problem. The user can not work with the model before it has been loaded. The problems begin when writing the document: the document write methods are called asynchronously, so the model is accessed at this time, but the user can do things at the same time in parallel through the UI and modify the model at the same time as it is saved - a big source for unpredicted behaviour, data-loss, crashes ...

    The documentation for performAsynchronousFileAccessUsingBlock only mentions accessing the "document" (assuming this means the document's file?). But I think serializing the file access is not enough; accessing the "in-memory" model must also be serialized. Or did I miss something?

    Regards,
    Mani
previous month may 2012 next month
MTWTFSS
  1 2 3 4 5 6
7 8 9 10 11 12 13
14 15 16 17 18 19 20
21 22 23 24 25 26 27
28 29 30 31      
Go to today