JavaScript is required to for searching.
Skip Navigation Links
Exit Print View
Oracle Solaris DHCP Service Developer's Guide     Oracle Solaris 11 Express 11/10
search filter icon
search icon

Document Information

Preface

1.  Overview of Solaris DHCP Data Access Architecture

2.  Architecture Features for Module Writers

Function Categories

Considerations for Multithreading

Synchronizing Access to File-System-Based Containers

Avoiding Update Collisions

Naming the Public Module and Data Store Containers

Public Module Name

Container Name

Container Record Formats

Passing Data Store Configuration Data

Upgrading Container Versions

Data Service Configuration and DHCP Management Tools

Public Module Management Bean API Functions

getComponent()

Synopsis

Description

getDescription()

Synopsis

Description

getPath()

Synopsis

Description

getAdditional()

Synopsis

Description

Public Module Management Bean Packaging Requirements

3.  Service Provider Layer API

4.  Code Samples and Testing

Index

Synchronizing Access to File-System-Based Containers

When you write a public module that provides access to containers in a local file-system-based data service (the data service runs on the same machine as the DHCP server), it can be difficult to synchronize access to the underlying data service between multiple processes and threads.

The Solaris DHCP synchronization service simplifies the design of public modules using local file-system-based data services by pushing synchronization up into the Framework Configuration Layer. When you design your module to use this framework, your code becomes simpler and your design cleaner.

The synchronization service provides public modules with per-container exclusive synchronization of all callers of the add_d?(), delete_d?(), and modify_d?() Service Provider Layer API calls. This means that if one thread is inside add_dn() for a given DHCP network container, no other thread may be inside add_dn(), delete_dn(), modify_dn() or lookup_dn() for that same container. However, other threads may be within routines that provide no synchronization guarantees, such as close_dn().

Per-container shared synchronization of all callers of lookup_d?() is also provided. Thus, there may be many threads performing a lookup on the same container, but only one thread may perform an add, delete, or modify operation.

The synchronization service is implemented as a daemon (/usr/lib/inet/dsvclockd). Lock manager requests are made on the public module's behalf through Framework Configuration Layer API calls. The interface between the Framework Configuration layer and the lock manager daemon uses the Solaris doors interprocess communication mechanism. See, for example, door_create and door_call.

The Framework Configuration layer starts the dsvclockd daemon if a public module requests synchronization and the daemon is not already running. The daemon automatically exits if it manages no locks for 15 minutes. To change this interval, you can create a /etc/default/dsvclockd file and set the IDLE default to the number of idle minutes before the daemon terminates.

A public module notifies the Framework Configuration Layer that it requires synchronization services by providing the following global variable in one of the module's source files:

dsvc_synchtype_t dsvc_synchtype = DSVC_SYNCH_DSVCD;

A public module notifies the Framework Configuration Layer that it does not require synchronization services by including the following global variable in one of the module's source files:

dsvc_synchtype_t dsvc_synchtype = DSVC_SYNCH_NONE;

DSVC_SYNCH_DSVCD and DSVC_SYNCH_NONE are the only two synchronization types that exist currently.