[cf-dev] Potential problem due to lack of fairness in thread scheduling?

[Abhijan Bhattacharyya <abhijan.bhattacharyya@xxxxxxx>]

I did a bit of digging down into the issue I mentioned in the previous mail. It seems that the problem is , when the code is run for a very short period, for example when the client is not going to wait for the response or the time out is too short, the requester is not guaranteed to be scheduled by the system within that time as the lock may be acquired by the code waiting for response which leads to system exit based on the conditions.

I did a small change. Tried to make the lock re-entrant so that there is fairness in scheduling. So, I did the following:

Changed the 'lock' object in 'Request.java' :
from:
private Object lock;

to:
private ReentrantLock lock

and initialized it inside waitForResponse(long timeout) as:

            synchronized (this) {
                if (lock == null)
                    //Abhijan lock = new Object();
                    lock = new ReentrantLock(true);
            }

Now, the behaviour of the client seems to be deterministic, i.e., the code does not exit without letting the client send the request.

I am not really an expert in this. Would request the Californium experts to please let me know if this is a sensible approach.
 
Regards
Abhijan Bhattacharyya
Associate Consultant
Scientist, Innovation Lab, Kolkata, India
Tata Consultancy Services
Mailto: abhijan.bhattacharyya@xxxxxxx
Website: http://www.tcs.com
____________________________________________
Experience certainty. IT Services
Business Solutions
Consulting
____________________________________________


-----cf-dev-bounces@xxxxxxxxxxx wrote: -----

To: cf-dev@xxxxxxxxxxx
From: Abhijan Bhattacharyya
Sent by: cf-dev-bounces@xxxxxxxxxxx
Date: 03/11/2017 08:08PM
Subject: [cf-dev] Sender thread does not seem to function while setting the timeout to very small value


Hi,
I was doing couple of small experiments and unfortunately failed. Any help will be highly appreciated.

Firstly, I was trying a simple PUT. But before  calling the put I set the timeout to very low (see the code snippet below). But nothing goes out from the client.

/*************** code ******************/
client.setTimeout(1);

response = client.put("ABC", MediaTypeRegistry.TEXT_PLAIN);
/****************************************/

If I just make timeout(3), then it works! Any, specific reason to it?


Then, I tried to make the requester not to wait for the response and I tried a quick hack with the logic inside waitForResponse() method inside Request.java as below. But then I see the behaviour of the client becoming unpredictable. At times the request is sent. At times the sender does not work. Seems I am missing something with the synchronization between the receiver and the sender thread.


/************************* Code ****************************/
synchronized (lock) {
            /********** This is new ***********/
            //brute force - make it not wait//
            this.setNoWait(true);
            /******************************/
            //Abhijan while (this.response == null && !isCanceled() && !isTimedOut() && !isRejected()) {
            while (this.response == null && !isCanceled() && !isTimedOut() && !isRejected() &&!isNoWait()) { //New
                lock.wait(timeout);
                long now = System.currentTimeMillis();       
                // timeout expired?
                if (timeout > 0 && expired <= now) {
                    // break loop since response is still null
                    break;
                }
            }
            Response r = this.response;
            this.response = null;
            return r;
        }

/*********************************************************/

/************* setNoWait() *************/
    /**
     * {@inheritDoc}
     *
     * If the request should not wait for a response it will wake up all threads that
     * are currently waiting for a response.
     */
    @Override
    public void setNoWait(boolean doNotWait) {
        super.setNoWait(doNotWait);
        if (doNotWait && lock != null) {
            synchronized (lock) {
                lock.notifyAll();
            }
        }
    }
    /**********************************/

And inside Message.java I introduce the following:

/**************  NoWait  *********************/
    /**
     * Checks if this message is ste for no-response. If no-response is set to
     * indicate dis-interest in all the responses then the client should not wait.
     * TODO: Granularity not considered at this moment.
     *
     * @return true, if no-response
     */
    public boolean isNoWait() {
        return doNotWait;
    }
    public void setNoWait(boolean doNotWait) {
        this.doNotWait = doNotWait;
    }
    /*******************************************/

Regards
Abhijan Bhattacharyya
Associate Consultant
Scientist, Innovation Lab, Kolkata, India
Tata Consultancy Services
Mailto: abhijan.bhattacharyya@xxxxxxx
Website: http://www.tcs.com
____________________________________________
Experience certainty. IT Services
Business Solutions
Consulting
____________________________________________

=====-----=====-----=====
Notice: The information contained in this e-mail
message and/or attachments to it may contain
confidential or privileged information. If you are
not the intended recipient, any dissemination, use,
review, distribution, printing or copying of the
information contained in this e-mail message
and/or attachments to it are strictly prohibited. If
you have received this communication in error,
please notify us by reply e-mail or telephone and
immediately and permanently delete the message
and any attachments. Thank you

_______________________________________________
cf-dev mailing list
cf-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/cf-dev