All of lore.kernel.org
 help / color / mirror / Atom feed
From: John Richard Moser <nigelenki@comcast.net>
To: linux-c-programming@vger.kernel.org, linux-gcc@vger.kernel.org
Subject: Objective-C Objects and Locking
Date: Tue, 06 Jul 2004 15:17:46 -0400	[thread overview]
Message-ID: <40EAFADA.3040807@comcast.net> (raw)

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

I'm writing up my own objective-c framework, something to use in place
of OpenStep/Cocoa/etc.  So, I'm in complete control of what happens with
my base object, SVObject (which ironically inherits from Object :).

I'm attempting to implement a swizzling subsystem which allows any
SVObject inheriting object to dynamicly handle swizzle requests safely
and effectively.  Because I want to work in a threaded environment, I
need to lock properly.

What I'm thinking is to use a mutex lock around all members that may not
run during a swizzle and deflect in-swizzle calls to the new swizzle
master.  The current logic I'm pondering is:

- -(void) someMemberThatIsAffected {
~  if ([my_swizzle_lock tryReadLock]) { /*Can we lock?*/
~    /*
~     * We couldn't lock, so we wait for the swizzle lock to become
~     * unlocked, then send the message to whatever swizzled us.
~     */
~    [my_swizzle_lock readLock];
~    [my_swizzle_master someMemberThatIsAffected];
~  }
~  else { /*Or we just complete*/
~    ...
~  }
~  [my_swizzle_lock unlock];
}

A swizzle would -writeLock my_swizzle_lock, so this would detect the lock.

Here's the issue I have:  Looking at this logic, if the entire swizzle
is done between the actual message passing call and the -tryReadLock,
which is quite plausible in an SMP situation, this will fail to detect.
~ Also, the new object may want to pass messages down to this object, so
I can't just feed all messages upwards.

I don't want to abandon the idea of supplying simplistic swizzling;
however, I would have to detect in-progress swizzles reliably.  I can't
think of anything to atomicize, and don't know how to make chunks of
code atomic anyway.

Any thoughts?
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFA6vrZhDd4aOud5P8RAqioAKCOswm5y2OM0ShzROOXvR5R2BEC6QCfW6hQ
Sf/+aJXpdPUkBDsmq3zcJig=
=PyRP
-----END PGP SIGNATURE-----

                 reply	other threads:[~2004-07-06 19:17 UTC|newest]

Thread overview: [no followups] expand[flat|nested]  mbox.gz  Atom feed

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=40EAFADA.3040807@comcast.net \
    --to=nigelenki@comcast.net \
    --cc=linux-c-programming@vger.kernel.org \
    --cc=linux-gcc@vger.kernel.org \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.