[CDRIVER-145] bson_oid_gen() is not thread-safe Created: 29/May/12  Updated: 03/May/17  Resolved: 09/Nov/13

Status: Closed
Project: C Driver
Component/s: None
Affects Version/s: 0.5.2, 0.6
Fix Version/s: TBD

Type: Bug Priority: Major - P3
Reporter: Pawel Assignee: Gary Murakami
Resolution: Done Votes: 0
Labels: bson
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

*



 Description   

bson_oid_gen() is not thread-safe.
It uses static 'incr' integer variable to increment. When enough threads accessing the method, the returned oid will be the same as returned just previously.



 Comments   
Comment by Christian Hergert [ 09/Nov/13 ]

This is fixed in libbson. You can use the default bson_context_t which uses a thread-safe atomic, or keep your own copy for other potential optimizations.

Comment by Frank J. Lhota [ 19/Mar/13 ]

One more change should be made before closing out this issue: in bson_oid_gen(), we have the declaration

static int fuzz = 0;

Even if we register a thread-safe fuzz function, multiple threads can end up using the same fuzz, because the fuzz value is stored in the static fuzz variable, shared by all the threads.

This problem has a simple fix: don't declare fuzz as static.

Comment by Gary Murakami [ 28/Jul/12 ]

Re: bson_oid_gen()
/**

  • Set a function to be used to generate the incrementing part
  • of an object id (last four bytes). If you need thread-safety
  • in generating object ids, you should set this function.
    *
  • @param func a pointer to a function that returns an int.
    */
    MONGO_EXPORT void bson_set_oid_inc( int ( *func )( void ) );
Comment by Gary Murakami [ 28/Jul/12 ]

Another concern:
mongo.c:52:static char _hp[sizeof(hp->host)+12];
just make it a non-static automatic stack-allocated

Comment by Pawel [ 09/Jun/12 ]

Apparently, this is already solved by having allowing external functions to generated both the incremented part of the OID and its fuzz. This issue can be closed.

Comment by Pawel [ 29/May/12 ]

May be GCC atomics can be considered, at least as a #if
http://gcc.gnu.org/onlinedocs/gcc-4.1.1/gcc/Atomic-Builtins.html

Generated at Wed Feb 07 21:08:35 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.