Does using a lock have better performance than using a local (single application) semaphore?

I read this blog from msdn : Producer consumer solution on msdn

and I didn't like their solution to the problem because there are always 20 elements left in the queue.

So instead, I thought about using a 'Semaphore' that will be available only in my app (I just won't name it in the constructor), but I don't know how it will effect the app's performance.

Does anyone have an idea if it'll affect the performance? What are the other considerations to use a lock and not 'Semaphore'?

edited Nov 21 '18 at 9:26

Brenton Scott

439

asked Aug 15 '10 at 21:38

Adibe7

1,55052234

This is built into .NET 4.0 and works well out of the box..

– Steven Sudit
Aug 15 '10 at 23:34

add a comment |

Does using a lock have better performance than using a local (single application) semaphore?

I read this blog from msdn : Producer consumer solution on msdn

and I didn't like their solution to the problem because there are always 20 elements left in the queue.

So instead, I thought about using a 'Semaphore' that will be available only in my app (I just won't name it in the constructor), but I don't know how it will effect the app's performance.

Does anyone have an idea if it'll affect the performance? What are the other considerations to use a lock and not 'Semaphore'?

edited Nov 21 '18 at 9:26

Brenton Scott

439

asked Aug 15 '10 at 21:38

Adibe7

1,55052234

This is built into .NET 4.0 and works well out of the box..

– Steven Sudit
Aug 15 '10 at 23:34

add a comment |

Does using a lock have better performance than using a local (single application) semaphore?

I read this blog from msdn : Producer consumer solution on msdn

and I didn't like their solution to the problem because there are always 20 elements left in the queue.

So instead, I thought about using a 'Semaphore' that will be available only in my app (I just won't name it in the constructor), but I don't know how it will effect the app's performance.

Does anyone have an idea if it'll affect the performance? What are the other considerations to use a lock and not 'Semaphore'?

edited Nov 21 '18 at 9:26

Brenton Scott

439

asked Aug 15 '10 at 21:38

Adibe7

1,55052234

Does using a lock have better performance than using a local (single application) semaphore?

I read this blog from msdn : Producer consumer solution on msdn

and I didn't like their solution to the problem because there are always 20 elements left in the queue.

So instead, I thought about using a 'Semaphore' that will be available only in my app (I just won't name it in the constructor), but I don't know how it will effect the app's performance.

Does anyone have an idea if it'll affect the performance? What are the other considerations to use a lock and not 'Semaphore'?

c# multithreading thread-safety locking semaphore

edited Nov 21 '18 at 9:26

Brenton Scott

439

asked Aug 15 '10 at 21:38

Adibe7

1,55052234

edited Nov 21 '18 at 9:26

Brenton Scott

439

asked Aug 15 '10 at 21:38

Adibe7

1,55052234

edited Nov 21 '18 at 9:26

Brenton Scott

439

edited Nov 21 '18 at 9:26

Brenton Scott

439

edited Nov 21 '18 at 9:26

Brenton Scott

439

asked Aug 15 '10 at 21:38

Adibe7

1,55052234

asked Aug 15 '10 at 21:38

Adibe7

1,55052234

asked Aug 15 '10 at 21:38

Adibe7

1,55052234

This is built into .NET 4.0 and works well out of the box..

– Steven Sudit
Aug 15 '10 at 23:34

add a comment |

This is built into .NET 4.0 and works well out of the box..

– Steven Sudit
Aug 15 '10 at 23:34

This is built into .NET 4.0 and works well out of the box..

– Steven Sudit
Aug 15 '10 at 23:34

add a comment |

4 Answers
4

active

oldest

votes

Lock(obj) is the same as Monitor.Enter(obj); A lock is basicaly an unary semaphore. If you have a number of instances of the same ressource (N) you use a semaphore with the initialization value N. A lock is mainly used to ensure that a code section is not executed by two threads at the same time.

So a lock can be implemented using a semaphore with initialization value of 1. I guess that Monitor.Enter is more performant here but I have no real information about that. A test will be of help here. Here is a SO thread that handels about performance.

For your problem a blocking queue would be the solution. (producer consumer) I suggest this very good SO thread.

Here is another good source of information about Reusable Parallel Data Structures.

edited May 23 '17 at 12:17

Community♦

answered Aug 15 '10 at 21:49

schoetbi

5,56833858

Thanks for the answer but it's not really answering my question :)

– Adibe7
Aug 15 '10 at 22:45

I added a link to another so thread that handels the performance. Does this help you?

– schoetbi
Aug 16 '10 at 13:56

Please note: a sempahore (at operating system level) uses the far faster hardware lock, so implementing a lock using a semaphore seems a bit contraproductive.

– Offler
Jan 11 '13 at 10:52

Lock is in fact different than semaphore, considering ie reentrancy: lock is reentrant, while semaphore is not. Semaphore can be however released within other thread.

– Kędrzu
Mar 20 '15 at 13:07

add a comment |

In general: If your consumer thread manages to process each data item quickly enough, then the kernel-mode transition will incur a (possibly significant) bit of overhead. In that case a user-mode wrapper which spins for a while before waiting on the semaphore will avoid some of that overhead.

A monitor (with mutual exclusion + condition variable) may or may not implement spinning. That MSDN article's implementation didn't, so in this case there's no real difference in performance. Anyway, you're still going to have to lock in order to dequeue items, unless you're using a lock-free queue.

answered Aug 16 '10 at 7:44

wj32

6,47622234

add a comment |

The solution in the MSDN article has a bug where you'll miss an event if SetEvent is called twice by the producer in quick succession whilst the consumer is processing the last item it retrieves from the queue.

Have a look at this article for a different implementation using Monitor instead:

http://wekempf.spaces.live.com/blog/cns!D18C3EC06EA971CF!672.entry

answered Aug 15 '10 at 21:52

theburningmonk

8,589115094

Thanks for the answer, but your post has a different bug.. The check in the consumer that checks if the queue size not equals to zero is problematic. example : the queue holds one product. two clients do the check simultaneously and enter the while loop, one locks the monitor and the other one is waiting. the first one consumes the product (so there are no products left!), and then exits the monitor. Now the second one enters the monitor, and try to dequeue an empty queue.. fatal error.

– Adibe7
Aug 15 '10 at 22:52

Actually, when the second consumer gets woken up in the inner while loop and reacquires the lock it'll continue the while loop and check whether the queue is empty before it decides to continue and dequeue from the queue so you won't get the error you just mentioned. However, as the author did mention it's only a partial implementation and it's not doing anything with the dequeued item.

– theburningmonk
Aug 16 '10 at 7:06

add a comment |

TLDR I just ran my own benchmark and in my setup, it seems that lock is running almost twice as fast as SemaphoreSlim(1).

Specs:

.NET Core 2.1.5

Windows 10

2 physical cores (4 logical) @2.5 GHz

The test:

I tried running 2, 4 and 6 Tasks in parallel, each of them doing 1M of operations of accessing a lock, doing a trivial operation and releasing it. The code looks as follows:

await semaphoreSlim1.WaitAsync();

// other case: lock(obj) {...}



if(1 + 1 == 2)

{

    count++;

}        



semaphoreSlim1.Release();

Results
For each case, lock ran almost twice as fast as SemaphoreSlim(1) (e.g. 205ms vs 390ms, using 6 parallel tasks).

Please note, I do not claim that it is any faster on an infinite number of other setups.

answered Nov 21 '18 at 8:24

eddyP23

1,69211333

Rather one should compare lock vs. SpinLock. For more information look for "PerformanceCharacteristicsOfSyncPrimitives.pdf" here: microsoft.com/en-us/download/details.aspx?id=12594

– KarloX
Jan 17 at 10:12

add a comment |

Your Answer

StackExchange.ifUsing("editor", function () {
StackExchange.using("externalEditor", function () {
StackExchange.using("snippets", function () {
StackExchange.snippets.init();
});
});
}, "code-snippets");

StackExchange.ready(function() {
var channelOptions = {
tags: "".split(" "),
id: "1"
};
initTagRenderer("".split(" "), "".split(" "), channelOptions);

StackExchange.using("externalEditor", function() {
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled) {
StackExchange.using("snippets", function() {
createEditor();
});
}
else {
createEditor();
}
});

function createEditor() {
StackExchange.prepareEditor({
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: true,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: 10,
bindNavPrevention: true,
postfix: "",
imageUploader: {
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
},
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
});

}
});

draft saved

draft discarded

Sign up or log in

StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});

Post as a guest

Name

Required, but never shown

StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f3489382%2fdoes-using-a-lock-have-better-performance-than-using-a-local-single-application%23new-answer', 'question_page');
}
);

Post as a guest

Name

Required, but never shown

4 Answers
4

active

oldest

votes

4 Answers
4

active

oldest

votes

For your problem a blocking queue would be the solution. (producer consumer) I suggest this very good SO thread.

Here is another good source of information about Reusable Parallel Data Structures.

edited May 23 '17 at 12:17

Community♦

answered Aug 15 '10 at 21:49

schoetbi

5,56833858

Thanks for the answer but it's not really answering my question :)

– Adibe7
Aug 15 '10 at 22:45

I added a link to another so thread that handels the performance. Does this help you?

– schoetbi
Aug 16 '10 at 13:56

Please note: a sempahore (at operating system level) uses the far faster hardware lock, so implementing a lock using a semaphore seems a bit contraproductive.

– Offler
Jan 11 '13 at 10:52

Lock is in fact different than semaphore, considering ie reentrancy: lock is reentrant, while semaphore is not. Semaphore can be however released within other thread.

– Kędrzu
Mar 20 '15 at 13:07

add a comment |

For your problem a blocking queue would be the solution. (producer consumer) I suggest this very good SO thread.

Here is another good source of information about Reusable Parallel Data Structures.

edited May 23 '17 at 12:17

Community♦

answered Aug 15 '10 at 21:49

schoetbi

5,56833858

Thanks for the answer but it's not really answering my question :)

– Adibe7
Aug 15 '10 at 22:45

I added a link to another so thread that handels the performance. Does this help you?

– schoetbi
Aug 16 '10 at 13:56

Please note: a sempahore (at operating system level) uses the far faster hardware lock, so implementing a lock using a semaphore seems a bit contraproductive.

– Offler
Jan 11 '13 at 10:52

Lock is in fact different than semaphore, considering ie reentrancy: lock is reentrant, while semaphore is not. Semaphore can be however released within other thread.

– Kędrzu
Mar 20 '15 at 13:07

add a comment |

For your problem a blocking queue would be the solution. (producer consumer) I suggest this very good SO thread.

Here is another good source of information about Reusable Parallel Data Structures.

edited May 23 '17 at 12:17

Community♦

answered Aug 15 '10 at 21:49

schoetbi

5,56833858

For your problem a blocking queue would be the solution. (producer consumer) I suggest this very good SO thread.

Here is another good source of information about Reusable Parallel Data Structures.

edited May 23 '17 at 12:17

Community♦

answered Aug 15 '10 at 21:49

schoetbi

5,56833858

edited May 23 '17 at 12:17

Community♦

edited May 23 '17 at 12:17

Community♦

edited May 23 '17 at 12:17

Community♦

answered Aug 15 '10 at 21:49

schoetbi

5,56833858

answered Aug 15 '10 at 21:49

schoetbi

5,56833858

answered Aug 15 '10 at 21:49

schoetbi

5,56833858

Thanks for the answer but it's not really answering my question :)

– Adibe7
Aug 15 '10 at 22:45

I added a link to another so thread that handels the performance. Does this help you?

– schoetbi
Aug 16 '10 at 13:56

Please note: a sempahore (at operating system level) uses the far faster hardware lock, so implementing a lock using a semaphore seems a bit contraproductive.

– Offler
Jan 11 '13 at 10:52

Lock is in fact different than semaphore, considering ie reentrancy: lock is reentrant, while semaphore is not. Semaphore can be however released within other thread.

– Kędrzu
Mar 20 '15 at 13:07

add a comment |

Thanks for the answer but it's not really answering my question :)

– Adibe7
Aug 15 '10 at 22:45

I added a link to another so thread that handels the performance. Does this help you?

– schoetbi
Aug 16 '10 at 13:56

Please note: a sempahore (at operating system level) uses the far faster hardware lock, so implementing a lock using a semaphore seems a bit contraproductive.

– Offler
Jan 11 '13 at 10:52

Lock is in fact different than semaphore, considering ie reentrancy: lock is reentrant, while semaphore is not. Semaphore can be however released within other thread.

– Kędrzu
Mar 20 '15 at 13:07

Thanks for the answer but it's not really answering my question :)

– Adibe7
Aug 15 '10 at 22:45

I added a link to another so thread that handels the performance. Does this help you?

– schoetbi
Aug 16 '10 at 13:56

Please note: a sempahore (at operating system level) uses the far faster hardware lock, so implementing a lock using a semaphore seems a bit contraproductive.

– Offler
Jan 11 '13 at 10:52

Lock is in fact different than semaphore, considering ie reentrancy: lock is reentrant, while semaphore is not. Semaphore can be however released within other thread.

– Kędrzu
Mar 20 '15 at 13:07

add a comment |

answered Aug 16 '10 at 7:44

wj32

6,47622234

add a comment |

answered Aug 16 '10 at 7:44

wj32

6,47622234

add a comment |

answered Aug 16 '10 at 7:44

wj32

6,47622234

answered Aug 16 '10 at 7:44

wj32

6,47622234

answered Aug 16 '10 at 7:44

wj32

6,47622234

answered Aug 16 '10 at 7:44

wj32

6,47622234

answered Aug 16 '10 at 7:44

wj32

6,47622234

add a comment |

Have a look at this article for a different implementation using Monitor instead:

http://wekempf.spaces.live.com/blog/cns!D18C3EC06EA971CF!672.entry

answered Aug 15 '10 at 21:52

theburningmonk

8,589115094

Thanks for the answer, but your post has a different bug.. The check in the consumer that checks if the queue size not equals to zero is problematic. example : the queue holds one product. two clients do the check simultaneously and enter the while loop, one locks the monitor and the other one is waiting. the first one consumes the product (so there are no products left!), and then exits the monitor. Now the second one enters the monitor, and try to dequeue an empty queue.. fatal error.

– Adibe7
Aug 15 '10 at 22:52

Actually, when the second consumer gets woken up in the inner while loop and reacquires the lock it'll continue the while loop and check whether the queue is empty before it decides to continue and dequeue from the queue so you won't get the error you just mentioned. However, as the author did mention it's only a partial implementation and it's not doing anything with the dequeued item.

– theburningmonk
Aug 16 '10 at 7:06

add a comment |

Have a look at this article for a different implementation using Monitor instead:

http://wekempf.spaces.live.com/blog/cns!D18C3EC06EA971CF!672.entry

answered Aug 15 '10 at 21:52

theburningmonk

8,589115094

Thanks for the answer, but your post has a different bug.. The check in the consumer that checks if the queue size not equals to zero is problematic. example : the queue holds one product. two clients do the check simultaneously and enter the while loop, one locks the monitor and the other one is waiting. the first one consumes the product (so there are no products left!), and then exits the monitor. Now the second one enters the monitor, and try to dequeue an empty queue.. fatal error.

– Adibe7
Aug 15 '10 at 22:52

Actually, when the second consumer gets woken up in the inner while loop and reacquires the lock it'll continue the while loop and check whether the queue is empty before it decides to continue and dequeue from the queue so you won't get the error you just mentioned. However, as the author did mention it's only a partial implementation and it's not doing anything with the dequeued item.

– theburningmonk
Aug 16 '10 at 7:06

add a comment |

Have a look at this article for a different implementation using Monitor instead:

http://wekempf.spaces.live.com/blog/cns!D18C3EC06EA971CF!672.entry

answered Aug 15 '10 at 21:52

theburningmonk

8,589115094

Have a look at this article for a different implementation using Monitor instead:

http://wekempf.spaces.live.com/blog/cns!D18C3EC06EA971CF!672.entry

answered Aug 15 '10 at 21:52

theburningmonk

8,589115094

answered Aug 15 '10 at 21:52

theburningmonk

8,589115094

answered Aug 15 '10 at 21:52

theburningmonk

8,589115094

answered Aug 15 '10 at 21:52

theburningmonk

8,589115094

Thanks for the answer, but your post has a different bug.. The check in the consumer that checks if the queue size not equals to zero is problematic. example : the queue holds one product. two clients do the check simultaneously and enter the while loop, one locks the monitor and the other one is waiting. the first one consumes the product (so there are no products left!), and then exits the monitor. Now the second one enters the monitor, and try to dequeue an empty queue.. fatal error.

– Adibe7
Aug 15 '10 at 22:52

Actually, when the second consumer gets woken up in the inner while loop and reacquires the lock it'll continue the while loop and check whether the queue is empty before it decides to continue and dequeue from the queue so you won't get the error you just mentioned. However, as the author did mention it's only a partial implementation and it's not doing anything with the dequeued item.

– theburningmonk
Aug 16 '10 at 7:06

add a comment |

Thanks for the answer, but your post has a different bug.. The check in the consumer that checks if the queue size not equals to zero is problematic. example : the queue holds one product. two clients do the check simultaneously and enter the while loop, one locks the monitor and the other one is waiting. the first one consumes the product (so there are no products left!), and then exits the monitor. Now the second one enters the monitor, and try to dequeue an empty queue.. fatal error.

– Adibe7
Aug 15 '10 at 22:52

Actually, when the second consumer gets woken up in the inner while loop and reacquires the lock it'll continue the while loop and check whether the queue is empty before it decides to continue and dequeue from the queue so you won't get the error you just mentioned. However, as the author did mention it's only a partial implementation and it's not doing anything with the dequeued item.

– theburningmonk
Aug 16 '10 at 7:06

Thanks for the answer, but your post has a different bug.. The check in the consumer that checks if the queue size not equals to zero is problematic. example : the queue holds one product. two clients do the check simultaneously and enter the while loop, one locks the monitor and the other one is waiting. the first one consumes the product (so there are no products left!), and then exits the monitor. Now the second one enters the monitor, and try to dequeue an empty queue.. fatal error.

– Adibe7
Aug 15 '10 at 22:52

Actually, when the second consumer gets woken up in the inner while loop and reacquires the lock it'll continue the while loop and check whether the queue is empty before it decides to continue and dequeue from the queue so you won't get the error you just mentioned. However, as the author did mention it's only a partial implementation and it's not doing anything with the dequeued item.

– theburningmonk
Aug 16 '10 at 7:06

add a comment |

TLDR I just ran my own benchmark and in my setup, it seems that lock is running almost twice as fast as SemaphoreSlim(1).

Specs:

.NET Core 2.1.5

Windows 10

2 physical cores (4 logical) @2.5 GHz

The test:

I tried running 2, 4 and 6 Tasks in parallel, each of them doing 1M of operations of accessing a lock, doing a trivial operation and releasing it. The code looks as follows:

await semaphoreSlim1.WaitAsync();

// other case: lock(obj) {...}



if(1 + 1 == 2)

{

    count++;

}        



semaphoreSlim1.Release();

Results
For each case, lock ran almost twice as fast as SemaphoreSlim(1) (e.g. 205ms vs 390ms, using 6 parallel tasks).

Please note, I do not claim that it is any faster on an infinite number of other setups.

answered Nov 21 '18 at 8:24

eddyP23

1,69211333

Rather one should compare lock vs. SpinLock. For more information look for "PerformanceCharacteristicsOfSyncPrimitives.pdf" here: microsoft.com/en-us/download/details.aspx?id=12594

– KarloX
Jan 17 at 10:12

add a comment |

TLDR I just ran my own benchmark and in my setup, it seems that lock is running almost twice as fast as SemaphoreSlim(1).

Specs:

.NET Core 2.1.5

Windows 10

2 physical cores (4 logical) @2.5 GHz

The test:

I tried running 2, 4 and 6 Tasks in parallel, each of them doing 1M of operations of accessing a lock, doing a trivial operation and releasing it. The code looks as follows:

await semaphoreSlim1.WaitAsync();

// other case: lock(obj) {...}



if(1 + 1 == 2)

{

    count++;

}        



semaphoreSlim1.Release();

Results
For each case, lock ran almost twice as fast as SemaphoreSlim(1) (e.g. 205ms vs 390ms, using 6 parallel tasks).

Please note, I do not claim that it is any faster on an infinite number of other setups.

answered Nov 21 '18 at 8:24

eddyP23

1,69211333

Rather one should compare lock vs. SpinLock. For more information look for "PerformanceCharacteristicsOfSyncPrimitives.pdf" here: microsoft.com/en-us/download/details.aspx?id=12594

– KarloX
Jan 17 at 10:12

add a comment |

TLDR I just ran my own benchmark and in my setup, it seems that lock is running almost twice as fast as SemaphoreSlim(1).

Specs:

.NET Core 2.1.5

Windows 10

2 physical cores (4 logical) @2.5 GHz

The test:

I tried running 2, 4 and 6 Tasks in parallel, each of them doing 1M of operations of accessing a lock, doing a trivial operation and releasing it. The code looks as follows:

await semaphoreSlim1.WaitAsync();

// other case: lock(obj) {...}



if(1 + 1 == 2)

{

    count++;

}        



semaphoreSlim1.Release();

Results
For each case, lock ran almost twice as fast as SemaphoreSlim(1) (e.g. 205ms vs 390ms, using 6 parallel tasks).

Please note, I do not claim that it is any faster on an infinite number of other setups.

answered Nov 21 '18 at 8:24

eddyP23

1,69211333

TLDR I just ran my own benchmark and in my setup, it seems that lock is running almost twice as fast as SemaphoreSlim(1).

Specs:

.NET Core 2.1.5

Windows 10

2 physical cores (4 logical) @2.5 GHz

The test:

I tried running 2, 4 and 6 Tasks in parallel, each of them doing 1M of operations of accessing a lock, doing a trivial operation and releasing it. The code looks as follows:

await semaphoreSlim1.WaitAsync();

// other case: lock(obj) {...}



if(1 + 1 == 2)

{

    count++;

}        



semaphoreSlim1.Release();

Results
For each case, lock ran almost twice as fast as SemaphoreSlim(1) (e.g. 205ms vs 390ms, using 6 parallel tasks).

Please note, I do not claim that it is any faster on an infinite number of other setups.

answered Nov 21 '18 at 8:24

eddyP23

1,69211333

answered Nov 21 '18 at 8:24

eddyP23

1,69211333

answered Nov 21 '18 at 8:24

eddyP23

1,69211333

answered Nov 21 '18 at 8:24

eddyP23

1,69211333

Rather one should compare lock vs. SpinLock. For more information look for "PerformanceCharacteristicsOfSyncPrimitives.pdf" here: microsoft.com/en-us/download/details.aspx?id=12594

– KarloX
Jan 17 at 10:12

add a comment |

Rather one should compare lock vs. SpinLock. For more information look for "PerformanceCharacteristicsOfSyncPrimitives.pdf" here: microsoft.com/en-us/download/details.aspx?id=12594

– KarloX
Jan 17 at 10:12

Rather one should compare lock vs. SpinLock. For more information look for "PerformanceCharacteristicsOfSyncPrimitives.pdf" here: microsoft.com/en-us/download/details.aspx?id=12594

– KarloX
Jan 17 at 10:12

add a comment |

draft saved

draft discarded

Thanks for contributing an answer to Stack Overflow!

Please be sure to answer the question. Provide details and share your research!

But avoid …

Asking for help, clarification, or responding to other answers.

Making statements based on opinion; back them up with references or personal experience.

To learn more, see our tips on writing great answers.

draft saved

draft discarded

Sign up or log in

StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});

Post as a guest

Name

Required, but never shown

Post as a guest

Name

Required, but never shown

Sign up or log in

StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});

Post as a guest

Name

Required, but never shown

Sign up or log in

StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});

Post as a guest

Name

Required, but never shown

Sign up or log in

StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});

Post as a guest

Name

Required, but never shown

Name

Required, but never shown

Name

Required, but never shown

This page is only for reference, If you need detailed information, please check here

Search This Blog

Ufyukyu