Some test text!


Get started

Quick start - view a documentDownload PDFTron SDKIntegrate with GradleIntegrate manuallyAdd license keyPermissionsRun samplesUpdate to latest versionTroubleshooting


Document lockingDocument saving

Document Viewer

OverviewShow a document in an ActivityShow a document in a FragmentViewer configurationToolManager configurationDay and Night themesOpen from online URL

Document Viewer components

OverviewPDFViewCtrlReflowQuick menuCustomize quick menuAnnotation toolbarAnnotation style editorCustomize annotation style editorPage sliderList containerAnnotation listDocument outlineUser bookmark listThumbnail browserAdd pages dialogCrop pages dialogRotate pages dialogView mode dialog

Annotation and collaboration

OverviewRead only modeDisable annotation creation and editingDefault annotation propertiesChange tool modeEventsOverride annotation handlingShow and hide existing annotationsUndo and redoRealtime collaborationTool class hierarchy

Advanced customization

OverviewAdd a custom view to a pageCreate a custom toolPage color modePage fit modePage layout modeScrolling directionRight-to-left support



Parsing and extraction


Digital signatures


Form filling






Advanced topics

PrintUnderstand coordinatesGenerate page thumbnailsChange annotation propertiesDelete annotations

Other frameworks



ProGuardLocalizationIcon cheat sheet

PDF Processing API

What is PDFNet?Opening a documentSerializing (saving) a documentWorking with pagesWorking with Page ContentWorking with BookmarksWorking with Interactive Forms (AcroForms)PDF SecurityLow-level PDF APIError handling
Document lockingkeyboard_arrow_down

Document locking

In this document
chevron_rightPDFDoc lock
chevron_rightLocking in the PDFTron API
chevron_rightClient side locking
chevron_rightMigration of earlier code
chevron_rightOpting out
chevron_rightAPI calls which can acquire a write lock

As computing devices become more parallel in nature, PDFTron is evolving to allow developers to leverage this power in new and exciting ways. PDFTron version 6.0 introduces new locking semantics which allow for concurrent access of a PDFDoc instance. This was done to improve performance during interactive viewing (simultaneous rendering, text extraction, etc.), as well as to open up the possibility for new use cases (parallel rendering). This article introduces the locking system, and will get you on your way to developing parallel applications with PDFTron SDK.

linkPDFDoc lock

PDFTron uses a recursive read/write locking system. Multiple threads can hold a read lock on the document, but only one thread can hold a write lock at any given time. A thread can acquire an equivalent or weaker lock as many times as it likes without causing a deadlock. In other words, the following is valid:

However, a thread cannot acquire a write lock while holding a read lock. Because one can only acquire a write lock when no read locks are held, this situation would inevitably lead to a deadlock. To avoid this scenario, PDFTron will throw a runtime exception whenever the situation occurs.

linkLocking in the PDFTron API

Some of our API calls internally acquire a write lock on the document. As a result, these calls can also throw a runtime exception if they are invoked while holding a read lock. This is noted in each method's documentation. Additionally, you will find a complete list of those methods at the end of this article.

In general, the parts of our library that manage the UI will maintain document locks. For the lower level calls which actually modify the document, you are responsible for maintaining document locks.

linkClient side locking

PDFTron provides the following APIs for locking the document:

For convenience, PDFViewCtrl exposes similar methods, which will be applied to the document currently associated with the control. Additionally, the PDFViewCtrl.DocLock method takes a cancel_rendering parameter, which will interrupt all worker threads currently accessing the document. This allows you to acquire the write lock as fast as possible:


At the low level, a PDFDoc uses an input filter to access its PDF data. this data could be stored on the file system, in a memory buffer, or over a network. Now that PDFTron supports concurrent access of PDFDoc across many threads; these input filters must also be made thread-safe. StdFile, which was not a thread-safe filter, is no longer available. Instead, you should now use the new MappedFile filter, which provides thread-safe and efficient read access on a file. Custom user filters are still supported, although they are now wrapped in an internal filter that guarantees thread safety.

linkMigration of earlier code

The new locking system is backwards compatible, meaning previous calls to PDFDoc.Lock now acquire a write lock. If you would like to take advantage of the ability to read a PDF concurrently, it is your responsibility to review document locks and determine whether it is safe to downgrade them to a read lock.

linkOpting out

Conversely, if you are happy with the existing 'one document, one thread' model previously used in PDFTron 5.9., you can continue to work with this system. No change is required on your behalf.

linkAPI calls which can acquire a write lock