# Re: Thread safety for providers

David Brownell (David.Brownell@Eng)
Mon, 16 Jun 1997 18:18:35 -0700

- Messages sorted by: [ date ][ thread ][ subject ][ author ]
- Next message: gretaturgot75.mmed: "SocketMulticast"
- Previous message: Roland Schemers: "Re: Thread safety for providers"
- Maybe in reply to: Steve Burnett: "Thread safety for providers"

    Date: Mon, 16 Jun 1997 18:18:35 -0700

    From: David.Brownell@Eng (David Brownell)

    Message-Id: <199706170118.SAA10131@argon.eng.sun.com>

    To: java-security@web2.javasoft.com, burnettS@RSA.COM

    Subject: Re: Thread safety for providers

> As far as we know, Java has no straight-forward way of locking an object for
> periods of time lasting longer than one method call. There are ways of having
> a "mutex" object that is locked and unlocked by specific, proprietary
> methods, but no specific Java programming practice has been defined.

Roland noted "synchronized (object) { ... }" does this ... within the
scope of a set of high-level calls.

> Furthermore, the JCE will support an init-update-final type of API on
> encryption objects, which seems to require the type of locking described
> above if a provider's security package is to be thread-safe.

I'm not sure I see this -- application critical sections can arrange
operation sequencing (like a bunch of "update" method calls) within
a critical section on their own, and they don't need low level data
objects to provide mutual exclusion primitives in order to do that.

Either the "synchronized (object) {...}" construct, or synchronized
methods, suffice to define those higher level critical sections.

> What kind of requirements does Sun intend to place on the thread safety of
> security packages, given that there is no accepted, standardized way of
> locking objects for longer than one method call?

Why are you thinking that the synchronization would be done on a low
level object, rather than an application-level critical section?

The usual rule is that interfaces should NOT include "synchronized";
critical sections are an implementation detail which may reflect through
API invariants, but those are normally application-specific critical
sections rather than ones showing through a general purpose API.

For example, so long as only one thread updates a Signature object
at a time, what does it matter that each buffer was handled by a
different thread? The application would sequence the buffers and
could use any convenient object to get the sequencing done right.

- Dave

- Next message: gretaturgot75.mmed: "SocketMulticast"
- Previous message: Roland Schemers: "Re: Thread safety for providers"
- Maybe in reply to: Steve Burnett: "Thread safety for providers"