Search Results

Search found 7 results on 1 pages for 'reentrantreadwritelock'.

Page 1/1 | 1 

  • Documentation for java.util.concurrent.locks.ReentrantReadWriteLock

    - by Andrei Taptunov
    Disclaimer: I'm not very good at Java and just comparing read/writer locks between C# and Java to understand this topic better & decisions behind both implementations. There is JavaDoc about ReentrantReadWriteLock. It states the following about upgrade/downgrade for locks: Lock downgrading ... However, upgrading from a read lock to the write lock is not possible. It also has the following example that shows manual upgrade from read lock to write lock: // Here is a code sketch showing how to exploit reentrancy // to perform lock downgrading after updating a cache void processCachedData() { rwl.readLock().lock(); if (!cacheValid) { // upgrade lock manually #1: rwl.readLock().unlock(); // must unlock first to obtain writelock #2: rwl.writeLock().lock(); if (!cacheValid) { // recheck ... } ... } use(data); rwl.readLock().unlock(); Does it mean that actually the sample from above may not behave correctly in some cases - I mean there is no lock between lines #1 & #2 and underlying structure is exposed to changes from other threads. So it can not be considered as the correct way to upgrade the lock or do I miss something here?

    Read the article

  • Is lock returned by ReentrantReadWriteLock equivalent to it's read and write locks?

    - by Todd
    Hello, I have been looking around for the answer to this, but no joy. In Java, is using the lock created by ReentrantReadWriteLock equivalent to getting the read and write locks as returned by readLock.lock() and writeLock.lock()? In other words, can I expect the read and write locks associated with the ReentrantReadWriteLock to be requested and held by synchronizing on the ReentrantReadWriteLock? My gut says "no" since any object can be used for synchronization. I wouldn't think that there would be special behavior for ReentrantReadWriteLock. However, special behavior is the corner case of which I may not be aware. Thanks, Todd

    Read the article

  • Java ReentrantReadWriteLocks - how to safely acquire write lock?

    - by Andrzej Doyle
    I am using in my code at the moment a ReentrantReadWriteLock to synchronize access over a tree-like structure. This structure is large, and read by many threads at once with occasional modifications to small parts of it - so it seems to fit the read-write idiom well. I understand that with this particular class, one cannot elevate a read lock to a write lock, so as per the Javadocs one must release the read lock before obtaining the write lock. I've used this pattern successfully in non-reentrant contexts before. What I'm finding however is that I cannot reliably acquire the write lock without blocking forever. Since the read lock is reentrant and I am actually using it as such, the simple code lock.getReadLock().unlock(); lock.getWriteLock().lock() can block if I have acquired the readlock reentrantly. Each call to unlock just reduces the hold count, and the lock is only actually released when the hold count hits zero. EDIT to clarify this, as I don't think I explained it too well initially - I am aware that there is no built-in lock escalation in this class, and that I have to simply release the read lock and obtain the write lock. My problem is/was that regardless of what other threads are doing, calling getReadLock().unlock() may not actually release this thread's hold on the lock if it acquired it reentrantly, in which case the call to getWriteLock().lock() will block forever as this thread still has a hold on the read lock and thus blocks itself. For example, this code snippet will never reach the println statement, even when run singlethreaded with no other threads accessing the lock: final ReadWriteLock lock = new ReentrantReadWriteLock(); lock.getReadLock().lock(); // In real code we would go call other methods that end up calling back and // thus locking again lock.getReadLock().lock(); // Now we do some stuff and realise we need to write so try to escalate the // lock as per the Javadocs and the above description lock.getReadLock().unlock(); // Does not actually release the lock lock.getWriteLock().lock(); // Blocks as some thread (this one!) holds read lock System.out.println("Will never get here"); So I ask, is there a nice idiom to handle this situation? Specifically, when a thread that holds a read lock (possibly reentrantly) discovers that it needs to do some writing, and thus wants to "suspend" its own read lock in order to pick up the write lock (blocking as required on other threads to release their holds on the read lock), and then "pick up" its hold on the read lock in the same state afterwards? Since this ReadWriteLock implementation was specifically designed to be reentrant, surely there is some sensible way to elevate a read lock to a write lock when the locks may be acquired reentrantly? This is the critical part that means the naive approach does not work.

    Read the article

  • Connecting Android device to multiple Bluetooth serial embedded peers

    - by TacB0sS
    I'm trying to find a solution for this setup: I have a single Android device, which I would like to connect to multiple serial embedded devices... And here is the thing, using the "Normal" way to retrieve the Bluetooth socket, doesn't work on all devices, and while it does, I can connect to multiple devices, and send and receive data to and from multiple devices. public final synchronized void connect() throws ConnectionException { if (socket != null) throw new IllegalStateException("Error socket is not null!!"); connecting = true; lastException = null; lastPacket = null; lastHeartBeatReceivedAt = 0; log.setLength(0); try { socket = fetchBT_Socket_Normal(); connectToSocket(socket); listenForIncomingSPP_Packets(); connecting = false; return; } catch (Exception e) { socket = null; logError(e); } try { socket = fetchBT_Socket_Workaround(); connectToSocket(socket); listenForIncomingSPP_Packets(); connecting = false; return; } catch (Exception e) { socket = null; logError(e); } connecting = false; if (socket == null) throw new ConnectionException("Error creating RFcomm socket for" + this); } private BluetoothSocket fetchBT_Socket_Normal() throws Exception { /* The getType() is a hex 0xXXXX value agreed between peers --- this is the key (in my case) to multiple connections in the "Normal" way */ String uuid = getType() + "1101-0000-1000-8000-00805F9B34FB"; try { logDebug("Fetching BT RFcomm Socket standard for UUID: " + uuid + "..."); socket = btDevice.createRfcommSocketToServiceRecord(UUID.fromString(uuid)); return socket; } catch (Exception e) { logError(e); throw e; } } private BluetoothSocket fetchBT_Socket_Workaround() throws Exception { Method m; int connectionIndex = 1; try { logDebug("Fetching BT RFcomm Socket workaround index " + connectionIndex + "..."); m = btDevice.getClass().getMethod("createRfcommSocket", new Class[]{int.class}); socket = (BluetoothSocket) m.invoke(btDevice, connectionIndex); return socket; } catch (Exception e1) { logError(e1); throw e1; } } private void connectToSocket(BluetoothSocket socket) throws ConnectionException { try { socket.connect(); } catch (IOException e) { try { socket.close(); } catch (IOException e1) { logError("Error while closing socket", e1); } finally { socket = null; } throw new ConnectionException("Error connecting to socket with" + this, e); } } And here is the thing, while on phones which the "Normal" way doesn't work, the "Workaround" way provides a solution for a single connection. I've searched far and wide, but came up with zip. The problem with the workaround is mentioned in the last link, both connection uses the same port, which in my case, causes a block, where both of the embedded devices can actually send data, that is not been processed on the Android, while both embedded devices can receive data sent from the Android. Did anyone handle this before? There is a bit more reference here, UPDATE: Following this (that I posted earlier) I wanted to give the mPort a chance, and perhaps to see other port indices, and how other devices manage them, and I found out the the fields in the BluetoothSocket object are different while it is the same class FQN in both cases: Detils from an HTC Vivid 2.3.4, uses the "workaround" Technic: The Socket class type is: [android.bluetooth.BluetoothSocket] mSocket BluetoothSocket (id=830008629928) EADDRINUSE 98 EBADFD 77 MAX_RFCOMM_CHANNEL 30 TAG "BluetoothSocket" (id=830002722432) TYPE_L2CAP 3 TYPE_RFCOMM 1 TYPE_SCO 2 mAddress "64:9C:8E:DC:56:9A" (id=830008516328) mAuth true mClosed false mClosing AtomicBoolean (id=830007851600) mDevice BluetoothDevice (id=830007854256) mEncrypt true mInputStream BluetoothInputStream (id=830008688856) mLock ReentrantReadWriteLock (id=830008629992) mOutputStream BluetoothOutputStream (id=830008430536) **mPort 1** mSdp null mSocketData 3923880 mType 1 Detils from an LG-P925 2.2.2, uses the "normal" Technic: The Socket class type is: [android.bluetooth.BluetoothSocket] mSocket BluetoothSocket (id=830105532880) EADDRINUSE 98 EBADFD 77 MAX_RFCOMM_CHANNEL 30 TAG "BluetoothSocket" (id=830002668088) TYPE_L2CAP 3 TYPE_RFCOMM 1 TYPE_SCO 2 mAccepted false mAddress "64:9C:8E:B9:3F:77" (id=830105544600) mAuth true mClosed false mConnected ConditionVariable (id=830105533144) mDevice BluetoothDevice (id=830105349488) mEncrypt true mInputStream BluetoothInputStream (id=830105532952) mLock ReentrantReadWriteLock (id=830105532984) mOutputStream BluetoothOutputStream (id=830105532968) mPortName "" (id=830002606256) mSocketData 0 mSppPort BluetoothSppPort (id=830105533160) mType 1 mUuid ParcelUuid (id=830105714176) Anyone have some insight...

    Read the article

  • How would you gather client's data on Google App Engine without using Datastore/Backend Instances too much?

    - by ruslan
    I'm relatively new to StackExchange and not sure if it's appropriate place to ask design question. Site gives me a hint "The question you're asking appears subjective and is likely to be closed". Please let me know. Anyway.. One of the projects I'm working on is online survey engine. It's my first big commercial project on Google App Engine. I need your advice on how to collect stats and efficiently record them in DataStore without bankrupting me. Initial requirements are: After user finishes survey client sends list of pairs [ID (int) + PercentHit (double)]. This list shows how close answers of this user match predefined answers of reference answerers (which identified by IDs). I call them "target IDs". Creator of the survey wants to see aggregated % for given IDs for last hour, particular timeframe or from the beginning of the survey. Some surveys may have thousands of target/reference answerers. So I created entity public class HitsStatsDO implements Serializable { @Id transient private Long id; transient private Long version = (long) 0; transient private Long startDate; @Parent transient private Key parent; // fake parent which contains target id @Transient int targetId; private double avgPercent; private long hitCount; } But writing HitsStatsDO for each target from each user would give a lot of data. For instance I had a survey with 3000 targets which was answered by ~4 million people within one week with 300K people taking survey in first day. Even if we assume they were answering it evenly for 24 hours it would give us ~1040 writes/second. Obviously it hits concurrent writes limit of Datastore. I decided I'll collect data for one hour and save that, that's why there are avgPercent and hitCount in HitsStatsDO. GAE instances are stateless so I had to use dynamic backend instance. There I have something like this: // Contains stats for one hour private class Shard { ReadWriteLock lock = new ReentrantReadWriteLock(); Map<Integer, HitsStatsDO> map = new HashMap<Integer, HitsStatsDO>(); // Key is target ID public void saveToDatastore(); public void updateStats(Long startDate, Map<Integer, Double> hits); } and map with shard for current hour and previous hour (which doesn't stay here for long) private HashMap<Long, Shard> shards = new HashMap<Long, Shard>(); // Key is HitsStatsDO.startDate So once per hour I dump Shard for previous hour to Datastore. Plus I have class LifetimeStats which keeps Map<Integer, HitsStatsDO> in memcached where map-key is target ID. Also in my backend shutdown hook method I dump stats for unfinished hour to Datastore. There is only one major issue here - I have only ONE backend instance :) It raises following questions on which I'd like to hear your opinion: Can I do this without using backend instance ? What if one instance is not enough ? How can I split data between multiple dynamic backend instances? It hard because I don't know how many I have because Google creates new one as load increases. I know I can launch exact number of resident backend instances. But how many ? 2, 5, 10 ? What if I have no load at all for a week. Constantly running 10 backend instances is too expensive. What do I do with data from clients while backend instance is dead/restarting? Thank you very much in advance for your thoughts.

    Read the article

  • How can I gather client's data on Google App Engine without using Datastore/Backend Instances too much?

    - by ruslan
    One of the projects I'm working on is online survey engine. It's my first big commercial project on Google App Engine. I need your advice on how to collect stats and efficiently record them in DataStore without bankrupting me. Initial requirements are: After user finishes survey client sends list of pairs [ID (int) + PercentHit (double)]. This list shows how close answers of this user match predefined answers of reference answerers (which identified by IDs). I call them "target IDs". Creator of the survey wants to see aggregated % for given IDs for last hour, particular timeframe or from the beginning of the survey. Some surveys may have thousands of target/reference answerers. So I created entity public class HitsStatsDO implements Serializable { @Id transient private Long id; transient private Long version = (long) 0; transient private Long startDate; @Parent transient private Key parent; // fake parent which contains target id @Transient int targetId; private double avgPercent; private long hitCount; } But writing HitsStatsDO for each target from each user would give a lot of data. For instance I had a survey with 3000 targets which was answered by ~4 million people within one week with 300K people taking survey in first day. Even if we assume they were answering it evenly for 24 hours it would give us ~1040 writes/second. Obviously it hits concurrent writes limit of Datastore. I decided I'll collect data for one hour and save that, that's why there are avgPercent and hitCount in HitsStatsDO. GAE instances are stateless so I had to use dynamic backend instance. There I have something like this: // Contains stats for one hour private class Shard { ReadWriteLock lock = new ReentrantReadWriteLock(); Map<Integer, HitsStatsDO> map = new HashMap<Integer, HitsStatsDO>(); // Key is target ID public void saveToDatastore(); public void updateStats(Long startDate, Map<Integer, Double> hits); } and map with shard for current hour and previous hour (which doesn't stay here for long) private HashMap<Long, Shard> shards = new HashMap<Long, Shard>(); // Key is HitsStatsDO.startDate So once per hour I dump Shard for previous hour to Datastore. Plus I have class LifetimeStats which keeps Map<Integer, HitsStatsDO> in memcached where map-key is target ID. Also in my backend shutdown hook method I dump stats for unfinished hour to Datastore. There is only one major issue here - I have only ONE backend instance :) It raises following questions on which I'd like to hear your opinion: Can I do this without using backend instance ? What if one instance is not enough ? How can I split data between multiple dynamic backend instances? It hard because I don't know how many I have because Google creates new one as load increases. I know I can launch exact number of resident backend instances. But how many ? 2, 5, 10 ? What if I have no load at all for a week. Constantly running 10 backend instances is too expensive. What do I do with data from clients while backend instance is dead/restarting?

    Read the article

  • Java Memory Model: reordering and concurrent locks

    - by Steffen Heil
    Hi The java meomry model mandates that synchronize blocks that synchronize on the same monitor enforce a before-after-realtion on the variables modified within those blocks. Example: // in thread A synchronized( lock ) { x = true; } // in thread B synchronized( lock ) { System.out.println( x ); } In this case it is garanteed that thread B will see x==true as long as thread A already passed that synchronized-block. Now I am in the process to rewrite lots of code to use the more flexible (and said to be faster) locks in java.util.concurrent, especially the ReentrantReadWriteLock. So the example looks like this: // in thread A synchronized( lock ) { lock.writeLock().lock(); x = true; lock.writeLock().unlock(); } // in thread B synchronized( lock ) { lock.readLock().lock(); System.out.println( x ); lock.readLock().unlock(); } However, I have not seen any hints within the memory model specification that such locks also imply the nessessary ordering. Looking into the implementation it seems to rely on the access to volatile variables inside AbstractQueuedSynchronizer (for the sun implementation at least). However this is not part of any specification and moreover access to non-volatile variables is not really condsidered covered by the memory barrier given by these variables, is it? So, here are my questions: Is it safe to assume the same ordering as with the "old" synchronized blocks? Is this documented somewhere? Is accessing any volatile variable a memory barrier for any other variable? Regards, Steffen

    Read the article

1