linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: "Othman, Ossama" <ossama.othman@intel.com>
To: "Henri Häkkinen" <henuxd@gmail.com>,
	"gregkh@suse.de" <gregkh@suse.de>,
	"randy.dunlap@oracle.com" <randy.dunlap@oracle.com>,
	"alan@linux.intel.com" <alan@linux.intel.com>
Cc: "devel@driverdev.osuosl.org" <devel@driverdev.osuosl.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: RE: [PATCH] Staging: memrar: Moved memrar_allocator struct into memrar_allocator.c
Date: Wed, 23 Jun 2010 10:51:37 -0700	[thread overview]
Message-ID: <A5FE05C4C76E4C4CAB15D9962B96FC950CEA180A03@orsmsx510.amr.corp.intel.com> (raw)
In-Reply-To: <1276519227-4987-1-git-send-email-henuxd@gmail.com>

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset="utf-8", Size: 1617 bytes --]

Hi,

> Forward declared memrar_allocator in memrar_allocator.h and moved it
> to memrar_allocator.c file.  Implemented memrar_allocator_capacity(),
> memrar_allocator_largest_free_area(), memrar_allocoator_lock() and
> memrar_allocator_unlock().
...
> -	mutex_lock(&allocator->lock);
> -	r->largest_block_size = allocator->largest_free_area;
> -	mutex_unlock(&allocator->lock);
> +	memrar_allocator_lock(allocator);
> +	r->largest_block_size =
> memrar_allocator_largest_free_area(allocator);
> +	memrar_allocator_unlock(allocator);

I don't think it's necessary to expose the allocator lock.  Why not just grab the lock in memrar_allocator_largest_free_area() while the underlying struct field is being accessed and then unlock it before that function returns?  That would allow the allocator lock to remain an internal implementation detail.  We only need to ensure access to the struct field itself is synchronized, e.g.:

size_t memrar_allocator_largest_free_area(struct memrar_allocator *allocator)
{
	size_t tmp = 0;

	if (allocator != NULL) {
		mutex_lock(&allocator->lock);
		tmp = allocator->largest_free_area;
		mutex_unlock(&allocator->lock);
	}

	return tmp;
}

Certainly the allocator->largest_free_area value could be updated after the lock is released and by the time it is returned to the user (for statistical purposes), but at least the internal allocator state would remain consistent in the presences of multiple threads.

HTH,
-Ossama

ÿôèº{.nÇ+‰·Ÿ®‰­†+%ŠËÿ±éݶ\x17¥Šwÿº{.nÇ+‰·¥Š{±þG«éÿŠ{ayº\x1dʇڙë,j\a­¢f£¢·hšïêÿ‘êçz_è®\x03(­éšŽŠÝ¢j"ú\x1a¶^[m§ÿÿ¾\a«þG«éÿ¢¸?™¨è­Ú&£ø§~á¶iO•æ¬z·švØ^\x14\x04\x1a¶^[m§ÿÿÃ\fÿ¶ìÿ¢¸?–I¥

  reply	other threads:[~2010-06-23 17:51 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-06-14 12:40 [PATCH] Staging: memrar: Moved memrar_allocator struct into memrar_allocator.c Henri Häkkinen
2010-06-23 17:51 ` Othman, Ossama [this message]
2010-06-24  9:35   ` Fwd: " Henri Häkkinen
2010-06-24 17:46     ` Othman, Ossama
2010-06-23 22:17 ` Greg KH
  -- strict thread matches above, loose matches on Subject: below --
2010-06-14 11:54 Henri Häkkinen
2010-06-22 22:00 ` Greg KH

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=A5FE05C4C76E4C4CAB15D9962B96FC950CEA180A03@orsmsx510.amr.corp.intel.com \
    --to=ossama.othman@intel.com \
    --cc=alan@linux.intel.com \
    --cc=devel@driverdev.osuosl.org \
    --cc=gregkh@suse.de \
    --cc=henuxd@gmail.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=randy.dunlap@oracle.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).