transient volatile int busy;

  /** Package-private default constructor */
  Striped64() {}

  /** CASes the base field. */
  final boolean casBase(long cmp, long val) {
    return UNSAFE.compareAndSwapLong(this, baseOffset, cmp, val);
  }

  /** CASes the busy field from 0 to 1 to acquire lock. */
  final boolean casBusy() {

  transient volatile int busy;

  /** Package-private default constructor */
  Striped64() {}

  /** CASes the base field. */
  final boolean casBase(long cmp, long val) {
    return UNSAFE.compareAndSwapLong(this, baseOffset, cmp, val);
  }

  /** CASes the busy field from 0 to 1 to acquire lock. */
  final boolean casBusy() {

        "The security ID structure is invalid.", "The file system is full.", "All pipe instances are busy.", "All pipe instances are busy.",
        "The pipe state is invalid.", "All pipe instances are busy.", "No process is on the other end of the pipe.", "The pipe is being closed.",

        "No mapping between account names and security IDs was done.",
        "The security ID structure is invalid.",
        "All pipe instances are busy.",
        "All pipe instances are busy.",
        "The pipe state is invalid.",
        "All pipe instances are busy.",
        "No process is on the other end of the pipe.",
        "The pipe is being closed.",
        "Waiting for a process to open the other end of the pipe.",

      if (compareAndSet(currentRunner, blocker)) {
        // Thread.interrupt can throw arbitrary exceptions due to the nio InterruptibleChannel API
        // This will make sure that tasks don't get stuck busy waiting.
        // Some of this is fixed in jdk11 (see https://bugs.openjdk.java.net/browse/JDK-8198692) but
        // not all.  See the test cases for examples on how this can happen.
        try {

      if (compareAndSet(currentRunner, blocker)) {
        // Thread.interrupt can throw arbitrary exceptions due to the nio InterruptibleChannel API
        // This will make sure that tasks don't get stuck busy waiting.
        // Some of this is fixed in jdk11 (see https://bugs.openjdk.java.net/browse/JDK-8198692) but
        // not all.  See the test cases for examples on how this can happen.
        try {

   * requests become more likely to trigger expensive operations (a more extreme case of this
   * example is when a server has just booted, and it is mostly busy with getting itself up to
   * speed).
   *
   * To deal with such scenarios, we add an extra dimension, that of "past underutilization",

		{"-t", iptablesconstants.RAW, "-D", iptablesconstants.OUTPUT, "-j", ChainInpodOutput},
	}

	// these sometimes fail due to "Device or resource busy"
	optionalDeleteCmds := [][]string{
		// flush-then-delete our created chains
		{"-t", iptablesconstants.MANGLE, "-F", ChainInpodPrerouting},
		{"-t", iptablesconstants.MANGLE, "-F", ChainInpodOutput},

//
//	Generic S3 HTTP handler errors.
//
// //////////////////////////////////////////////////////////////////////
func errBusy(err error) *s3Error {
	return &s3Error{
		code:       "Busy",
		message:    "The service is unavailable. Please retry.",
		statusCode: 503,
		cause:      err,
	}
}

func errUnauthorizedAccess(err error) *s3Error {
	return &s3Error{

		readsAwait:        "Average time for read requests to be served on a drive",
		writesAwait:       "Average time for write requests to be served on a drive",
		percUtil:          "Percentage of time the disk was busy",
		usedBytes:         "Used bytes on a drive",
		totalBytes:        "Total bytes on a drive",
		usedInodes:        "Total inodes used on a drive",
		totalInodes:       "Total inodes on a drive",