aspose file tools*
The moose likes Threads and Synchronization and the fly likes Constructing the same thing through different approach of executors or locks Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


Win a copy of Spring in Action this week in the Spring forum!
JavaRanch » Java Forums » Java » Threads and Synchronization
Bookmark "Constructing the same thing through different approach of executors or locks" Watch "Constructing the same thing through different approach of executors or locks" New topic
Author

Constructing the same thing through different approach of executors or locks

sunder Nagar
Greenhorn

Joined: Dec 10, 2012
Posts: 7
Hi Guys,

I have developed a class that lets multi-threads to run sequentially, one at a time and in order. All the application code between this class' claimAccess function and release Access function will be executed only in one thread at one time. All other threads will wait in the queue until the previous thread completed.Please advise is this same thing can be built by any other way also , using executors ,locks,semaphore please advise..





Now Please advise is there any other way also by which we can achieve the same thing like through executors, semaphores, Locks..!! Please advise
I want to convert my application with executors like the below approach please advise how to convert that..Consider using Executors.newSingleThreadExecutor(). This is a thread pool with only one thread executing tasks. Next task will start execution only after first task is finished:

Emanuel Kadziela
Ranch Hand

Joined: Mar 24, 2005
Posts: 186
A Semaphore sounds like what you could use. It is a way to restrict the number of threads which will be allowed to concurrently run.
sunder Nagar
Greenhorn

Joined: Dec 10, 2012
Posts: 7
Emanuel Kadziela wrote:A Semaphore sounds like what you could use. It is a way to restrict the number of threads which will be allowed to concurrently run.


Hi Emanuel,

Could you Please post the code as I have done , That will be really helpful to understand.
sunder Nagar
Greenhorn

Joined: Dec 10, 2012
Posts: 7
tuntun tuntuns wrote:
Emanuel Kadziela wrote:A Semaphore sounds like what you could use. It is a way to restrict the number of threads which will be allowed to concurrently run.


Hi Emanuel,

Could you Please post the code as I have done , That will be really helpful to understand.


Hi Folks,

Please advise that either by semaphore how we can build the same approach or any other means of executor or latcher ,Please advise
Henry Wong
author
Sheriff

Joined: Sep 28, 2004
Posts: 18896
    
  40

sunder Nagar wrote:
Now Please advise is there any other way also by which we can achieve the same thing like through executors, semaphores, Locks..!! Please advise


An option is to use ReentrantLock class. The lock() and unlock() method would be similar to your claim and release methods. And if you turn on the fairness flag, it will be queued up.

Henry


Books: Java Threads, 3rd Edition, Jini in a Nutshell, and Java Gems (contributor)
Henry Wong
author
Sheriff

Joined: Sep 28, 2004
Posts: 18896
    
  40

sunder Nagar wrote:
tuntun tuntuns wrote:
Emanuel Kadziela wrote:A Semaphore sounds like what you could use. It is a way to restrict the number of threads which will be allowed to concurrently run.


Hi Emanuel,

Could you Please post the code as I have done , That will be really helpful to understand.


Hi Folks,

Please advise that either by semaphore how we can build the same approach or any other means of executor or latcher ,Please advise



As others has mentioned, the Semaphore class can also be used in a similar fashion -- just use the acquire() and release() methods in place of your claim and release methods. You will also have to set the permits to only one -- to prevent parallel execution. And set the fairness flag on, in order to have it queued up.

Personally, I think using the Semaphore class is an overkill versus the ReentrantLock class. You don't need the capability to handle more than one permit -- and the Semaphore class doesn't nest like the ReentrantLock class can.

Henry
sunder Nagar
Greenhorn

Joined: Dec 10, 2012
Posts: 7

As others has mentioned, the Semaphore class can also be used in a similar fashion -- just use the acquire() and release() methods in place of your claim and release methods. You will also have to set the permits to only one -- to prevent parallel execution. And set the fairness flag on, in order to have it queued up.

Personally, I think using the Semaphore class is an overkill versus the ReentrantLock class. You don't need the capability to handle more than one permit -- and the Semaphore class doesn't nest like the ReentrantLock class can.

Henry


Hi Henry,

Thanks a lot, Please post the code as I have done in term of Reentrant Lock that will be a great help, just convert my piece of code into the Reentrant one that will be a great help to understand.Thanks inadvance.
Henry Wong
author
Sheriff

Joined: Sep 28, 2004
Posts: 18896
    
  40

sunder Nagar wrote:
Hi Henry,

Thanks a lot, Please post the code as I have done in term of Reentrant Lock that will be a great help, just convert my piece of code into the Reentrant one that will be a great help to understand.Thanks inadvance.



First of all, you haven't shown any code that uses your AccessGate class, hence, nothing to convert from using the AccessGate class to the ReentrantLock class. Second, you wrote your own locking class -- isn't using a lock much easier to do? Do really need an example of using a lock? ... plus there is also an example in the JavaDocs.

Henry
sunder Nagar
Greenhorn

Joined: Dec 10, 2012
Posts: 7
Henry Wong wrote:
First of all, you haven't shown any code that uses your AccessGate class, hence, nothing to convert from using the AccessGate class to the ReentrantLock class. Second, you wrote your own locking class -- isn't using a lock much easier to do? Do really need an example of using a lock? ... plus there is also an example in the JavaDocs.

Henry


The code which is using my access gate is





Now please advise that if there is any other way to make access gate in any alternative way that is through re entrant or executor framework ..!!
Henry Wong
author
Sheriff

Joined: Sep 28, 2004
Posts: 18896
    
  40

sunder Nagar wrote:


Now please advise that if there is any other way to make access gate in any alternative way that is through re entrant or executor framework ..!!


Really?!? It will likely take five minutes to port this code from using the AccessGate class to using the ReentrantLock class. Ten minutes if you add the time to read the JavaDoc.

Just do it. It really isn't that hard.

Henry
sunder Nagar
Greenhorn

Joined: Dec 10, 2012
Posts: 7

Really?!? It will likely take five minutes to port this code from using the AccessGate class to using the ReentrantLock class. Ten minutes if you add the time to read the JavaDoc.
Just do it. It really isn't that hard.
Henry

Brother , I am stuck up at this , Please advise , any help on this will be really appreciated and will be thankful to you !!
Henry Wong
author
Sheriff

Joined: Sep 28, 2004
Posts: 18896
    
  40


First, it looks like this topic is cross posted ...

http://stackoverflow.com/questions/13784813/regarding-creating-synchronization-mechanism

JavaRanch does *allow* cross-posting, but with requirements ...

https://www.coderanch.com/how-to/java/BeForthrightWhenCrossPostingToOtherSites

Next time, please mention this up front.


Second, from the other topic, it looks like you didn't code the main() class or the MyThread class -- which now makes some sense. I was confused on how you can write the MyThread class, yet, can't make a five minute change to it.

Regardless, I think you need to take a step back and try again. If you don't understand the main() method, or the MyThread class, then I think you should just start over. You first need to understand the code that you currently have, before trying to make changes.

Henry
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: Constructing the same thing through different approach of executors or locks