Return-Path: X-Original-To: apmail-giraph-dev-archive@www.apache.org Delivered-To: apmail-giraph-dev-archive@www.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id 7B1EBF1C7 for ; Tue, 26 Mar 2013 17:40:34 +0000 (UTC) Received: (qmail 69475 invoked by uid 500); 26 Mar 2013 17:40:34 -0000 Delivered-To: apmail-giraph-dev-archive@giraph.apache.org Received: (qmail 69407 invoked by uid 500); 26 Mar 2013 17:40:34 -0000 Mailing-List: contact dev-help@giraph.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: dev@giraph.apache.org Delivered-To: mailing list dev@giraph.apache.org Received: (qmail 69395 invoked by uid 99); 26 Mar 2013 17:40:34 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 26 Mar 2013 17:40:34 +0000 X-ASF-Spam-Status: No, hits=-0.7 required=5.0 tests=RCVD_IN_DNSWL_LOW,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (athena.apache.org: domain of jwu65@gatech.edu designates 130.207.160.71 as permitted sender) Received: from [130.207.160.71] (HELO deliverator6.gatech.edu) (130.207.160.71) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 26 Mar 2013 17:40:27 +0000 Received: from deliverator6.gatech.edu (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id D93BEBDD3FA for ; Tue, 26 Mar 2013 13:40:05 -0400 (EDT) Received: from mail7.gatech.edu (mail7.gatech.edu [130.207.185.167]) by deliverator6.gatech.edu (Postfix) with ESMTP id 7FFF1BDD4DB for ; Tue, 26 Mar 2013 13:40:05 -0400 (EDT) Received: from mail-wi0-f178.google.com (mail-wi0-f178.google.com [209.85.212.178]) (Authenticated sender: jwu65) by mail7.gatech.edu (Postfix) with ESMTPSA id 4A90C2C897A for ; Tue, 26 Mar 2013 13:40:05 -0400 (EDT) Received: by mail-wi0-f178.google.com with SMTP id ez12so1252784wid.11 for ; Tue, 26 Mar 2013 10:40:03 -0700 (PDT) X-Received: by 10.194.58.202 with SMTP id t10mr26640560wjq.4.1364319603615; Tue, 26 Mar 2013 10:40:03 -0700 (PDT) MIME-Version: 1.0 Received: by 10.194.89.161 with HTTP; Tue, 26 Mar 2013 10:39:43 -0700 (PDT) From: Jiadong Wu Date: Tue, 26 Mar 2013 13:39:43 -0400 Message-ID: Subject: Is it necessary to lock partition access in ComputeCallable? To: dev@giraph.apache.org Content-Type: text/plain; charset=UTF-8 X-GT-AVAS-Version: 5.6.1.2065439, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2013.3.26.172720 X-GT-Spam-Details: Internal Mail X-GT-Spam-Rating: (0%) X-GT-True-Rating: (8%) X-Virus-Checked: Checked by ClamAV on apache.org Hi Giraphers, Just a small question. In ComputeCallable.computePartition, partition access is locked with synchronized(partition) to "make sure this is thread-safe across runs". I may not get the whole picture clearly, but this lock looks redundant to me. If every thread polled its partitionIds from a BlockingQueue, how could two threads work on the same partition? Thanks,