001/*
002 * Licensed to the Apache Software Foundation (ASF) under one or more
003 * contributor license agreements.  See the NOTICE file distributed with
004 * this work for additional information regarding copyright ownership.
005 * The ASF licenses this file to You under the Apache License, Version 2.0
006 * (the "License"); you may not use this file except in compliance with
007 * the License.  You may obtain a copy of the License at
008 *
009 *     http://www.apache.org/licenses/LICENSE-2.0
010 *
011 * Unless required by applicable law or agreed to in writing, software
012 * distributed under the License is distributed on an "AS IS" BASIS,
013 * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
014 * See the License for the specific language governing permissions and
015 * limitations under the License.
016 */
017package org.apache.commons.configuration2.sync;
018
019/**
020 * <p>
021 * An interface controlling synchronization of configuration instances.
022 * </p>
023 * <p>
024 * Each {@code Configuration} object derived from {@link org.apache.commons.configuration2.AbstractConfiguration
025 * AbstractConfiguration} has an associated {@code Synchronizer} object. Before an operation on the configuration is
026 * performed (e.g. a property read or an update), the {@code Synchronizer} is invoked. Depending on the concrete
027 * implementation of the {@code Synchronizer} used, the configuration can be made thread-safe.
028 * </p>
029 * <p>
030 * Whether a configuration has to be thread-safe or not is a matter of a concrete use case. For instance, an application
031 * that just reads some configuration settings on startup does need a thread-safe configuration implementation. A
032 * configuration in contrast which is shared between multiple components and updated concurrently should better be
033 * thread-safe. In order to satisfy both kinds of use cases, the support for thread-safety has been extracted out of the
034 * configuration implementation and refactored into this {@code Synchronizer} interface. By assigning different
035 * {@code Synchronizer} implementations to a configuration instance, the instance's support for concurrent access can be
036 * adapted to the concrete use case.
037 * </p>
038 * <p>
039 * The methods defined by this interface are similar to a <em>read-write lock</em>. The {@code Synchronizer} is notified
040 * when read or write operations start and end. A concrete implementation can then apply a specific policy to decide
041 * when threads need to block or when access to the configuration for the desired operation is granted.
042 * </p>
043 *
044 * @since 2.0
045 */
046public interface Synchronizer {
047    /**
048     * Notifies this {@code Synchronizer} that the current thread is going to start a read operation on the managed
049     * configuration. This call can block if a concrete implementation decides that the thread has to wait until a specific
050     * condition is fulfilled.
051     */
052    void beginRead();
053
054    /**
055     * Notifies this {@code Synchronizer} that the current thread is going to start a write operation on the managed
056     * configuration. This call may block. For instance, a concrete implementation may suspend the thread until all read
057     * operations currently active are finished,
058     */
059    void beginWrite();
060
061    /**
062     * Notifies this {@code Synchronizer} that the current thread has finished its read operation. This may cause other
063     * waiting threads to be granted access to the managed configuration.
064     */
065    void endRead();
066
067    /**
068     * Notifies this {@code Synchronizer} that the current thread has finished its write operation. This may cause other
069     * waiting threads to be granted access to the managed configuration.
070     */
071    void endWrite();
072}