Databases
StackOverflow2013
Postsdbo
PO
 

Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    primarykey
    data
    text
    <p>If you're talking Cocoa, the mutex functionality there is provided by <code>NSLock</code> and <code>NSRecursiveLock</code>.</p> <p>In order to properly protect non-atomic resource, you need these mutexes, lest multiple threads may try to change the data at the same time (leading to corruption) or use the data in a half-changed state (leading to invalid data).</p> <p>Your code would look something like this:</p> <pre><code>static NSLock session_id_lock; static unsigned int session_id = 1000; - (int) generateSessionID{ int new_id; [myLock lock]; new_id = session_id++; [myLock unlock]; return new_id; } </code></pre> <p>If you're not using Cocoa (or what little Cocoa programming I remember from my brief interlude with an iMac is so dimly remembered that it's near useless), just use the concept, translating it to whatever language or framework you have:</p> <ul> <li>lock the mutex before using or changing a protected resource.</li> <li>use or change the resource.</li> <li>unlock the mutex.</li> <li>bonus advice 1: lock the mutex as late as possible and unlock it as soon as possible.</li> <li>bonus advice 2: only lock what you need so you avoid unnecessary delays.</li> </ul> <p>Explaining that last point some more: if you synchronise on <code>self</code> for two totally unrelated things (say a session ID and a user ID), they will block each other despite the fact that it's not necessary to do so. I would prefer two separate mutexes to keep the granularity low.</p> <p>Of course, if you only have a mutex on the session ID alone (but see below for caveat), feel free to use <code>synchronized(self)</code> but I'd prefer to do it my way so I wouldn't get caught out adding another protected resource later.</p> <p>In any case (this is the caveat mentioned), you will probably find that synchronising on <code>self</code> would not adequately protect a static variable, which would be shared across multiple objects. The mutex should belong to the <em>data</em> rather than whatever is using it.</p>
    singulars
    1. This table or related slice is empty.
    1. POThread safe static variables objective c
      singulars
      1. PTQuestion
    1. PTAnswer
    1. USpaxdiablo
    1. USpaxdiablo
    plurals
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. POThread safe static variables objective c
      singulars
      1. PTQuestion
    1. This table or related slice is empty.
    1. VO
      singulars
      1. PO
      1. This table or related slice is empty.
      1. VTAcceptedByOriginator
    2. VO
      singulars
      1. PO
      1. This table or related slice is empty.
      1. VTUpMod
    3. VO
      singulars
      1. PO
      1. This table or related slice is empty.
      1. VTUpMod
    1. COI am coming from Java world, where you simply can do: static synchronized int generateID(){return sessionId++}. is this will be compatible if i do -(int) generateSessionID{synchronized(self){return session_id++;}}?
      singulars
      1. PO
      1. USUnis
    2. COI would think that would work okay though a lock on self (the object) is probably more broad than I would do. Instead, I would prefer a specific mutex so as to avoid mutex delays that were unnecessary (see my added bonus advice).
      singulars
      1. PO
      1. USpaxdiablo
    3. CO@user489579 Close, but you don't want to synchronize on `self` for an instance method that's accessing a static variable; maybe sync on `[self class]`, or on an object that's directly associated with the value you're modifying (e.g. wrap the int in an NSNumber and sync on the NSNumber).
      singulars
      1. PO
      1. USDavid Gelhar
 

Querying!

 
Guidance
A row detail

Detail views are divided into sections. All the information in the data section comes from columns in the selected row. The other sections display data from other, related rows.

Related data can be related in a to-one or a to-many fashion. Captions of data related in a to-many fashion link to a list view showing a filtered view of the table.

Try moving around until you find a non-empty to-many entry and click on the label to get to one. You can move back to the root by clicking on the database name in the header.

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload