[concurrency-interest] Critique my class ?

Peter Veentjer - Anchor Men p.veentjer at anchormen.nl
Thu Sep 22 07:28:33 EDT 2005


And you could use a Future of you realy need to wait for the result of
the execution. 

________________________________

Van: concurrency-interest-bounces at cs.oswego.edu
[mailto:concurrency-interest-bounces at cs.oswego.edu] Namens Peter
Veentjer - Anchor Men
Verzonden: donderdag 22 september 2005 13:17
Aan: Chris Burnley; concurrency-interest at altair.cs.oswego.edu
Onderwerp: RE: [concurrency-interest] Critique my class ?


 
Would it not be an idea the store all the requests for every thread in
the queue and periodically flush that queue? Now clients don`t have to
block untill they can write information to the channel.You can use a
bounded BlockingQueue to prevent that there are to many requests and you
can use a ScheduledExecutor to schedule a runnable for the flusing task.


 
________________________________

Van: concurrency-interest-bounces at cs.oswego.edu
[mailto:concurrency-interest-bounces at cs.oswego.edu] Namens Chris Burnley
Verzonden: donderdag 22 september 2005 12:09
Aan: concurrency-interest at altair.cs.oswego.edu
Onderwerp: [concurrency-interest] Critique my class ?


I have a use case where I've got several client threads that write to a
FileChannel but I must guarantee that the file gets synced for each
client. A file sync could take up to 40ms depending on the size of the
file. To get around this I want to buffer up the clients so I only have
to do the sync once every, say 50ms, thus drastically improving the
throughput at the cost of a little latency.

Question : is there something already available that would help me do
this sort of thing ? I thought maybe a cyclicbarrier but somehow it
didn't fit ( I'm not concerned with the number of clients waiting but
rather the time elapsed since last sync)

Otherwise, can anybody see anything wrong with the following
implementation ? (I've called it Switch for want of a better term). 


class Switch {

    private Lock lock = new ReentrantLock();

    private Condition condition = lock.newCondition();

    private boolean waiters;
    private Exception failure;
    
    /**
     * Lock, but only if there are waiters.
     * @return if the lock was acquired.
     */
    public boolean lockIfWaiters() {
        lock.lock();
        failure = null;
        if (!waiters) {
            lock.unlock();
            return false;
        }
        return true;
    }

    /**
     * Unlock the switch and notify all those that have been waiting.
     */
    public void unlockAndSignalAll() {
        waiters = false;
        condition.signalAll();
        lock.unlock();
    }
    
    /**
     * Indicate to waiters that the operation has failed.
     *
     */
    public void signalFailure(Exception cause){
        this.failure = cause;
        unlockAndSignalAll();
    }

    /**
     * Used by waiters on the switch. 
     * @throws InterruptedException
     */
    public void await() throws InterruptedException,
WaitFailureException{
        lock.lock();
        try {
            waiters = true;
            condition.await();
            if(failure != null)
                throw new WaitFailureException(failure);
        } finally {
            lock.unlock();
        }
    }
}

The clients call this method after they've written to the channel:


    protected void force() throws SyncFailedException {
        try {
            swtch.await();
        } catch (InterruptedException e) {
            throw new SyncFailedException(e.toString());
        } catch (WaitFailureException e) {
            throw new SyncFailedException(e.toString());        
        }
    }



and I have a scheduled task that does the actual file sync:

    class FileSyncer implements Runnable {

        public void run() {
            while (swtch.lockIfWaiters()) {
                try {
                    fileChannel.force(false);
                    swtch.unlockAndSignalAll();
                } catch (Exception e){
                    // error logging omitted
                    swtch.signalFalure(e);
                }
            }
        }
    }

regards, 

Chris Burnley

-------------- next part --------------
An HTML attachment was scrubbed...
URL: /pipermail/attachments/20050922/1957bb8f/attachment-0001.htm


More information about the Concurrency-interest mailing list