468,458 Members | 1,764 Online
Bytes | Developer Community
New Post

Home Posts Topics Members FAQ

Post your question to a community of 468,458 developers. It's quick & easy.

optimistic locking

I have global variable which is being shared between threads (problem
is not connected with thread). Without using any mutex i have do some
operation global variable in *consistent* way.
consider following code :

int i = 0

fun (int j)
{

i = i + j ; i = i * somefun(i,j) ; /*i meant here is, we are doing
lot of operations */
}
above func is being executed by threads, We can change the
implementation of func .however , we need to maintain what that fun
does on that variable.
How can we implement the concept of optimistic locking here. I got lot
defination of optimistic locking on internet .

But i couldnt find any implementation. So i thought of implementing one
small programme . Can we apply concept of optimistic locking here ?

my guess,here we need to write pure C code.

Sep 29 '06 #1
6 3241
if by optimistic locking you mean "an interlock that will work 99.999%
of the time", you could try something like:

int Busy = 0;
while( Busy ) sleepsometime();
Busy++;
while( Busy 1 ) { Busy--; sleepsometime(); Busy++; }
i = i * i - (i-j) * whatever;
Busy--;

Ad-hoc locks like this will work a lot of the time, just don't use them
for anything critical!

i.e. the value in "i" might sometimes not get updated properly if two
threads happened to barge thru the lock once in a while.

Sep 29 '06 #2

Ancient_Hacker wrote:
if by optimistic locking you mean "an interlock that will work 99.999%
of the time", you could try something like:
I meant http://en.wikipedia.org/wiki/Optimistic_locking
int Busy = 0;
while( Busy ) sleepsometime();
Busy++;
while( Busy 1 ) { Busy--; sleepsometime(); Busy++; }
i can see race condition here .
i = i * i - (i-j) * whatever;
Busy--;

Ad-hoc locks like this will work a lot of the time, just don't use them
for anything critical!

i.e. the value in "i" might sometimes not get updated properly if two
threads happened to barge thru the lock once in a while.
Oct 1 '06 #3
shaanxxx wrote:
>Busy++;
while( Busy 1 ) { Busy--; sleepsometime(); Busy++; }
i can see race condition here .
Then you have x-ray vision. Head to comp.programming.threads as you're
inferring threading and/or async signals.
Oct 1 '06 #4

Christopher Layne wrote:
shaanxxx wrote:
Busy++;
while( Busy 1 ) { Busy--; sleepsometime(); Busy++; }
i can see race condition here .

Then you have x-ray vision.
was I wrong? How that x-ray vision is connected to programming.

Head to comp.programming.threads as you're
inferring threading and/or async signals.

Thanks

Oct 2 '06 #5

shaanxxx wrote:
I have global variable which is being shared between threads
Outside the scope of C programming per se.
(problem is not connected with thread).
Nonsense - the problem is intimately connected _at least_ with the fact
that multiple threads are acting on the variable. If you had no
threads, you'd have no concurrency problem, unless you moved to
multiple processes and shared memory (all outside the scope of C
programming per se).
Without using any mutex i have do some
operation global variable in *consistent* way.
Atomic operations (compare_and_swap etc) may be appropriate, but will
be platform-specific at least in their implementation details.
How can we implement the concept of optimistic locking here. I got lot
defination of optimistic locking on internet .

But i couldnt find any implementation. So i thought of implementing one
small programme . Can we apply concept of optimistic locking here ?
More research, but I'm uncertain that this gets you anywhere without
some form of atomic operation.
my guess,here we need to write pure C code.
Highly unlikely - the issues (multiple "tasks" sharing access to data)
are outside what the C language itself was developed for. To do this at
all robustly, you'll need to use things beyond the C language.

Oct 2 '06 #6

ma**********@pobox.com wrote:
shaanxxx wrote:
I have global variable which is being shared between threads

Outside the scope of C programming per se.
(problem is not connected with thread).

Nonsense - the problem is intimately connected _at least_ with the fact
that multiple threads are acting on the variable. If you had no
threads, you'd have no concurrency problem, unless you moved to
multiple processes and shared memory (all outside the scope of C
programming per se).
I put above sentence so that this question will not removed from C
programming group.
Our approach for everything is pessimistic (called locking, LOCK
everything).

We have been using for long time so we always follow that.
Without using any mutex i have do some
operation global variable in *consistent* way.

Atomic operations (compare_and_swap etc) may be appropriate, but will
be platform-specific at least in their implementation details.
How can we implement the concept of optimistic locking here. I got lot
defination of optimistic locking on internet .

But i couldnt find any implementation. So i thought of implementing one
small programme . Can we apply concept of optimistic locking here ?

More research, but I'm uncertain that this gets you anywhere without
some form of atomic operation.
my guess,here we need to write pure C code.

Highly unlikely - the issues (multiple "tasks" sharing access to data)
are outside what the C language itself was developed for. To do this at
all robustly, you'll need to use things beyond the C language.
you can refer book on transaction processing by gim grey. it has
something for atomic operation "within c language". Still, I am not
sure what he has said in his books will work.

Oct 3 '06 #7

This discussion thread is closed

Replies have been disabled for this discussion.

Similar topics

16 posts views Thread by Nid | last post: by
1 post views Thread by Chris Huddle | last post: by
1 post views Thread by jimi_usenet | last post: by
2 posts views Thread by John | last post: by
reply views Thread by russganz | last post: by
1 post views Thread by =?Utf-8?B?Qi4gQ2hlcm5pY2s=?= | last post: by
1 post views Thread by =?Utf-8?B?Qi4gQ2hlcm5pY2s=?= | last post: by
8 posts views Thread by Roger.Noreply | last post: by
reply views Thread by NPC403 | last post: by
By using this site, you agree to our Privacy Policy and Terms of Use.